分叉两年的Valkey，不想只做缓存了

2024 年 3 月 20 日，Redis 一纸许可证变更，把开源内存数据库社区撕成了两半。当时不少人的判断是：分叉项目 Valkey 大概率活不长。17 个月过去，Valkey 不仅活着，还带着 12 位维护者、9 位委员会成员，站上了 OSS EU（2025 年 8 月 25–27 日，阿姆斯特丹）的讲台，开始谈论缓存之外的东西——同步复制、分层存储。这篇文章想讲清楚两件事：一个分叉项目凭什么活下来，以及它长大之后想去哪。

💥 分叉不是葬礼，是压力测试

开源圈流传一句老话：分叉容易，养活难。

2024 年 3 月 20 日，Redis 官方博客宣布从 7.4 版本起采用 RSALv2 与 SSPLv1 双许可，不再使用 BSD 三条款。云厂商一夜之间从最大贡献者变成了协议意义上的“竞争对手”。仅仅八天后——2024 年 3 月 28 日，Linux 基金会 发布官方公告，宣布牵头成立 Valkey：代码从 Redis 7.2 分叉，治理交给基金会，公告由 AWS、Google Cloud、Oracle、Ericsson、Snap 联合署名。那几天，几乎每个数据库相关的技术群都在刷屏，有人押注 Redis，有人赌 Valkey，争论从协议条款一路吵到“开源精神”该不该讲。

判断一个分叉项目会不会死，代码质量其实是最不重要的指标，真正要看的是治理结构。Valkey 交出的答卷是：17 个月时间，形成 12 位维护者、9 位委员会成员的班底。根据 Valkey 代码库中的 MAINTAINERS 文件与治理文档（GOVERNANCE.md），这些成员来自 AWS、Google Cloud、Oracle、Ericsson、Snap、Upstash 等不同公司，没有任何一家占据过半席位——没有一家企业能单方面决定项目走向。而各大厂商的投入不只是署名：AWS 的 ElastiCache、Google Cloud 的 Memorystore for Valkey 均在 2024 年内上线了托管 Valkey 服务，这背后是各自工程师团队的持续提交。这种“多公司共治”的结构，恰恰是各家云厂商愿意持续投入工程师时间的前提：投入不会被别人拿去做嫁衣。

过去十年，开源基础设施的博弈逻辑已经变了：数据库不再只是技术选型问题，而是云厂商与软件供应商之间的谈判筹码。分叉的本质，是把被单一供应商握住的筹码，重新摊回桌面上。Valkey 的存在本身，就是对整个行业的一次压力测试——测试对象不是代码，而是“没有单点控制权的开源项目能否持续演进”。目前给出的答案是：能。

17 个月的关键节点，按可查证的日期排出来是这样的：

• 2024 年 3 月 20 日 — Redis 官宣改用 RSALv2/SSPLv1 双许可（随 Redis 7.4 生效）
• 2024 年 3 月 28 日 — Linux 基金会宣布 Valkey，AWS、Google Cloud、Oracle、Ericsson、Snap 联合署名；首个版本 7.2.5 于随后数日内发布
• 2024 年 9 月 — Valkey 8.0 GA：吞吐较 7.2.5 提升约 74%，p99 延迟下降约 47%，AWS 基准测试中达到每秒约 120 万次请求
• 2025 年 3 月底 — Valkey 8.1 GA：部分数据结构内存占用降低约 20–30%，集群 slot 迁移原子化
• 2025 年 7 月底 — Valkey 8.2 GA：引入 sidecar 插件接口、Hash 字段级过期等能力
• 2025 年 8 月 25–27 日 — OSS EU 上，Olson 与 Söderqvist 公布同步复制与分层存储路线图

📈 性能是最硬的通行证

分叉项目洗掉“政治产物”的标签，靠的不是嗓门，是数字。

Valkey 刚宣布时，我身边不少架构师的第一反应是冷笑：“不就是换个名字的 Redis？”这种质疑很正常——没有企业愿意把生产缓存交给一个“情绪化分叉”。回应质疑的方式，Valkey 社区选的是基准测试。

2024 年 9 月