为什么我用 Valkey,不用 Redis
2024 年 3 月,Redis 公司宣布将 Redis 的核心协议从 BSD 改为 RSALv2 和 SSPLv1 双许可。这个消息在开源圈炸了锅。不到一周,Linux 基金会宣布成立 Valkey 项目——从 Redis 7.2.4 分支出来的完全兼容替代品。
我现在所有新项目都用 Valkey。这篇文章说清楚为什么。
Redis 到底出了什么问题
先回顾一下发生了什么。
2024 年 3 月 20 日,Redis 公司 CEO Rowan Trollope 发了一篇博客,宣布 Redis 从 7.4 版本开始不再使用 BSD 许可,改成 RSALv2(Redis Source Available License v2)和 SSPLv1(Server Side Public License v1)双许可。
这两个许可证对普通用户有影响吗?如果你只是 docker run redis 或者从 apt 安装 redis-server,短期看不出变化。
但对云厂商和做 Redis 托管服务的人来说——SSPLv1 基本上禁止你提供"Redis as a Service"。这意味着 AWS、Google Cloud、Azure 不能继续免费提供基于新版本 Redis 的托管服务。
问题是,这不仅仅是云厂商的事。我们日常用的很多库、框架、工具,底层嵌了 Redis。比如 Sidekiq 依赖 Redis,Celery 依赖 Redis,Laravel 的队列系统依赖 Redis。这些项目的维护者现在得做出选择:
- 继续用 Redis 7.2 以前的 BSD 版本(但不会有新特性了)
- 付费给 Redis 公司获取商业许可
- 迁移到 Valkey
Valkey 是什么
Valkey 是从 Redis 7.2.4 分支出来的,由 Linux 基金会托管,完全开源(BSD 许可)。项目的核心贡献者包括 AWS、Google Cloud、Oracle、Ericsson 和 Snap 的工程师——基本上就是被 Redis 新许可政策影响的那些公司。
名字也挺有意思。"Valkey"是 “Val” + “key” 的组合,Val 来自拉丁语 “valere”(强壮、有价值),key 就是键值对的那个 key。
技术上,Valkey 做到了什么程度:
完全兼容。 你用 redis-cli 连 Valkey 完全没问题。所有的 Redis 命令、数据结构(String、Hash、List、Set、Sorted Set、Stream、Bitmap、HyperLogLog、Geospatial)都支持。RESP 协议不变。你现有的 Redis 客户端代码一行不用改,把连接地址从 Redis 换成 Valkey 就行。
性能有改进。 Valkey 8.0 引入了多线程 I/O 处理,在高并发场景下吞吐量可以提升到单线程版本的数倍。还有对内存碎片化处理的改进——在大内存实例上,Valkey 的碎片率比 Redis 低。
社区治理。 Redis 现在是 Redis 公司一家说了算。Valkey 由 Linux 基金会下的技术指导委员会管理,成员来自不同公司。这意味着不会出现"某个公司某天早上醒来决定改许可证"的事。
为什么我选 Valkey
说个人原因:
第一,我不想被许可证问题绑架。今天 Redis 改 SSPL,明天它会不会再加限制?今年 Redis 7.4 改许可,明年 Redis 8.0 会不会再进一步?我不是云厂商,但我不敢赌我的使用场景永远不受影响。
第二,Valkey 是真正的社区驱动。Redis 公司在 2020 年把 Redis 模块改成 RSAL 的时候,我就觉得方向不对。现在彻底验证了。Valkey 有 Linux 基金会的治理结构,多个大公司贡献代码——这种模式比单一公司控制更可持续。
第三,功能上没有损失。我常用的所有 Redis 特性,Valkey 全有。而且 Valkey 8.0 的部分性能改进(多线程 I/O)甚至比 Redis 同期的社区版更强。
第四,迁移成本为零。把你项目里的 redis://localhost:6379 改成 valkey://localhost:6379,完事。如果你用的是 Docker,把 redis:7 镜像换成 valkey/valkey:8,完事。
Valkey 能完全平替 Redis 吗
到 2025 年中,答案基本是:能,但有几点要注意。
已经可以平替的:
- 所有核心数据结构:String、Hash、List、Set、Sorted Set、Stream、Bitmap、HyperLogLog、Geospatial
- 持久化:RDB、AOF 都支持
- 主从复制、哨兵模式、集群模式
- Pub/Sub 消息
- Lua 脚本(通过
EVAL) - 事务(MULTI/EXEC)
- 客户端兼容——所有主流 Redis 客户端库都直接兼容 Valkey
还在追赶的:
- Redis Stack 里的部分模块(RediSearch、RedisJSON、RedisTimeSeries、RedisBloom)——这些是 Redis 公司的闭源/限制许可产品,Valkey 团队在做自己的实现,但进度不一
- 一些 Redis 7.4+ 的新特性(比如 Hash 字段过期)——Valkey 8.0 有自己的路线图,不一定会 1:1 追 Redis
重要的现实:
绝大多数人用 Redis 从来没碰过 Redis Stack 的高级模块。你用 SET/GET/LPUSH/SADD/ZADD 就够了。对于这 90% 的用户,Valkey 是完美的平替——没有任何感知差异。
什么场景用 Valkey,什么场景还得 Redis
直接用 Valkey 的场景:
- Web 应用的 Session 存储
- API 限流计数器
- 消息队列(用 List 或 Stream)
- 排行榜、积分系统——Sorted Set 完美应对
- 分布式锁
- 缓存层——这是 Redis/Valkey 最经典的用法
- 任何你只是
SET/GET/EXPIRE的简单场景
可能还得用 Redis 的场景:
- 你重度依赖 RediSearch 做全文搜索——这是 Redis Stack 的模块,Valkey 的替代方案还没完全成熟
- 你用了 RedisJSON 做复杂的文档存储查询——同上
- 你的公司有 Redis 公司的企业许可,而且已经在付费了——那继续用没什么不好
- 你需要 Redis 7.4 某个特定新特性,而 Valkey 还没实现
存疑的场景:
- RedisTimeSeries 和 RedisBloom——部分客户端库已经有替代实现,但生产环境还得验证
实际怎么切换
Docker 用户:
# 之前
services:
cache:
image: redis:7-alpine
ports:
- "6379:6379"
# 之后
services:
cache:
image: valkey/valkey:8-alpine
ports:
- "6379:6379"
代码层面:
// 之前用 ioredis
import Redis from 'ioredis';
const redis = new Redis('redis://localhost:6379');
// 之后——完全一样,只是连接字符串变一下(甚至不变也行)
import Redis from 'ioredis';
const redis = new Redis('redis://localhost:6379'); // Valkey 完全兼容 Redis 协议
客户端库层面——所有主流 Redis 客户端都兼容 Valkey:ioredis、node-redis、redis-py、Jedis、Lettuce、go-redis、StackExchange.Redis。
最后
Redis 还是那个 Redis——技术上没毛病。但 Redis 公司做的事情让我没法信任它了。
我今天用你的软件,是基于"BSD 许可、开源社区驱动"的信任。你把许可改了,那信任就断了。Valkey 接过了 Redis 开源的那一面——不只是在代码上分叉了,在治理哲学上也分叉了。
对我个人来说,选 Valkey 不是因为 Redis 不好用,是因为我不想把基础设施的命运交到一家随时可能改许可的公司手里。
BSD 许可的 Valkey 跑在我服务器上,我晚上睡得踏实。就这么简单。