2024 年 3 月 20 日，Redis 的 GitHub 仓库悄悄换了一顶帽子。那天下午，Redis Ltd. 宣布将 Redis 7.4 及后续版本的许可证从 BSD-3 改为 RSALv2 和 SSPLv1 双协议，任选其一，但两者都不再是 OSI 认可的开源协议。
对于大多数普通用户来说，这条新闻的分量感觉很轻：不就是个许可证吗，跑起来不还是一样用？但在云厂商、平台工程师和企业 IT 部门那边，反应截然不同。AWS、Google Cloud、Oracle 在同一周内宣布支持一个还没正式成立的项目 Valkey，并承诺将它纳入 Linux Foundation 旗下。这种速度不像是临时起意，更像是早就备好了预案，就等一个触发器。
Valkey 在接下来的几个月里完成了从 fork 到稳定版的整个过程。到 2026 年，它已经发布了 8.x 系列，AWS ElastiCache 和 MemoryDB 都已经原生支持它作为 Redis 的替代选项。那个问题从”要不要迁移”变成了”什么时候迁移，怎么迁移”。
—
一次许可证变更，搅动了整个行业
要理解这场变化，得先搞清楚 Redis 改协议的具体含义。
SSPLv1 是 MongoDB 在 2018 年发明的一种协议，核心条款是：如果你用这个软件提供服务，你必须开放整个服务栈的源码。这对于云厂商来说几乎等于不可能接受。AWS 如果因为提供 ElastiCache 就得开放整个 AWS 基础设施的代码，那显然不现实。RSALv2 则限制了竞争性使用，禁止在不购买商业许可的情况下提供”实质上相同功能”的服务。
两个协议选一个，结果都是：云厂商要么付钱给 Redis Ltd.，要么离开。
这不是第一次有基础软件走这条路。HashiCorp 的 Terraform、Elastic 的 Elasticsearch 都走过类似的轨迹，结果都是催生出有力的 fork，OpenTofu 和 OpenSearch。Redis 这次的体量更大、用户更广，fork 的阵营也更快形成合力。
Valkey 的名字来源于”Value Key”，项目在 2024 年 3 月底正式成立，初始提交者里有来自 AWS、Google、Ericsson、Oracle 的工程师，还有几位原 Redis 核心维护者。Linux Foundation 提供了中立的治理结构，避免了项目被单一商业利益控制的风险。
—
切换有多难？答案出乎意料地简单
很多工程师第一反应是：换一个系统，迁移成本会不会很高？
Valkey 的答案是：几乎没有。
Valkey 完全兼容 Redis 的 RESP（Redis Serialization Protocol）协议。这意味着你现有的所有 Redis 客户端，不管是 Python 的 redis-py、Java 的 Jedis、Go 的 go-redis，还是 Node.js 的 ioredis，一行代码不用改，只要把连接字符串指向 Valkey 实例就行。
数据结构、命令集、持久化格式（RDB/AOF）在 Valkey 8.x 里都保持了高度兼容。常见的 String、Hash、List、Set、Sorted Set、Stream、Lua 脚本，用法和行为跟 Redis 7.x 基本一致。
这种”协议级兼容”是 Valkey 被大规模采用的核心原因。迁移不需要重写业务逻辑，不需要替换客户端库，甚至不需要修改配置文件里的大部分参数（端口默认都是 6379）。对于一个月活几千万的服务来说，这种平滑度已经接近零风险。
AWS 在 2024 年底就完成了 ElastiCache 的 Valkey 支持，并在官方文档里提供了从 Redis 到 Valkey 的迁移指南，整个过程描述为”将集群引擎版本升级”，跟升级一个小版本的操作复杂度差不多。
—
生产就绪度：一个合理的问题
对于任何 fork 项目，最正常的疑问是：它足够稳吗？背后有没有足够多的人维护？
Valkey 的情况比大多数 fork 要好一些，原因有几个层面。
首先是治理结构。Linux Foundation 的项目有一套标准化的治理流程，贡献者签 CLA，发版有明确的 release cycle，安全漏洞有专门的 CVE 响应通道。这不是某个公司的内部项目，意味着不会因为某家公司的商业决策而突然停更或转向。
其次是贡献者背景。Valkey 的活跃提交者里，有多位在 Redis 项目里积累了超过五年经验的工程师。他们对代码库的熟悉程度不低于任何新的 Redis 版本的开发者。从提交频率看，2025 年全年 Valkey 的代码提交量相当活跃，8.x 系列带来了若干性能改进和新特性。
第三是云厂商背书的重量。AWS 把 Valkey 做进了 ElastiCache，意味着 AWS 的 SLA 在某种程度上绑定了 Valkey 的可用性。这不是一个可以随便抛弃的实验性选项。
当然，Redis 也没有倒下。Redis Ltd. 仍在开发商业版本，Redis Stack 包含了向量搜索、JSON 文档、时间序列等扩展功能，这些在 Valkey 里目前支持程度有限。如果你的使用场景重度依赖这些扩展模块，迁移前需要认真评估。
—
性能：方向是有的，数字要小心
关于性能对比，网上流传着各种 benchmark，结论不一，需要谨慎对待。
可以确认的方向性结论是：Valkey 在 8.x 中引入了多线程 I/O 改进，在高并发读写场景下有一定的吞吐量提升。Redis 7.x 系列在 Redis Ltd. 的商业驱动下也持续有性能优化。两者在单机延迟表现上接近，差距不足以成为选型的决定性因素。
真正影响性能的往往不是引擎本身，而是网络拓扑、持久化策略、键过期策略、内存分配配置这些运维层面的细节。一个配置得当的 Valkey 实例，和一个配置得当的 Redis 实例，在大多数典型场景下行为差异很小。
如果你需要精确的 benchmark 数据来支持决策，建议用自己的业务流量模式做压测，而不是依赖第三方报告。不同的访问模式、键大小分布、命令组合，结论可能完全不同。
—
生态与客户端：没有你想的那么大的麻烦
一个常见担心是：Valkey 的生态够不够？
答案取决于你怎么定义”生态”。如果指的是客户端库，那几乎不是问题。所有 Redis 客户端本来就通过 RESP 协议通信，连接到 Valkey 和连接到 Redis 在客户端代码层面没有区别。主流语言的 Redis 客户端维护者已经陆续在文档里注明了 Valkey 兼容性。
如果指的是第三方集成，比如 Celery、Django Cache Framework、Spring Data Redis、Rails Cache Store，这些框架层面的集成同样受益于协议兼容，大多数不需要任何修改就能指向 Valkey。
如果指的是 Redis Modules 生态，比如 RedisJSON、RediSearch、RedisTimeSeries，这里存在真正的差异。这些模块是 Redis Ltd. 商业产品的一部分，Valkey 社区正在开发对应的开放实现（比如 valkey-search），但成熟度和功能完整性仍在追赶中。
以下是两者的核心对比：
| 维度 | Valkey 8.x | Redis 7.4+ |
|---|---|---|
| 许可证 | BSD-3（OSI 认可开源） | RSALv2 / SSPLv1（非开源） |
| 协议兼容 | 完全兼容 RESP2/RESP3 | — |
| 治理 | Linux Foundation | Redis Ltd. 商业公司 |
| 云托管 | AWS ElastiCache/MemoryDB、Google Memorystore | AWS（需商业授权）、Azure、GCP |
| 向量搜索 | valkey-search（开发中） | Redis Stack（成熟） |
| 多线程 I/O | 已改进（8.x） | 支持 |
| 社区活跃度 | 活跃，多厂商贡献 | 活跃，Redis Ltd. 主导 |
表格里没有”N/A”的格子，每个维度两边都有明确的状态。选型的时候可以直接对着自己的需求点过一遍。
—
迁移的实际操作
说完了背景和对比，最后来谈谈真正动手的部分。
自托管场景：如果你在自己的服务器或 Kubernetes 上跑 Redis，迁移到 Valkey 的路径是：用 Valkey 官方镜像替换 Redis 镜像，保持同样的端口和持久化配置，做一次 RDB 备份后替换实例。整个过程跟升级 Redis 大版本类似，主要风险点在持久化文件格式的兼容性，Valkey 8.x 能读取 Redis 7.x 的 RDB 文件，反过来不保证。所以迁移是单向的，做好备份，不要想着出问题再切回去。
云托管场景：在 AWS 上，可以通过 ElastiCache 控制台直接创建 Valkey 集群，或者在创建新集群时选择 Valkey 引擎。现有 Redis 集群的迁移需要通过备份恢复或数据同步工具（如 riot-redis）完成，不是原地切换。
客户端配置：把连接字符串里的主机名换成 Valkey 实例的地址，其他参数（端口、密码、连接池大小）通常不用动。如果你用的是 Redis Cluster 模式，Valkey 同样支持集群协议，拓扑配置方式一致。
—
什么时候该留在 Redis
说了这么多 Valkey 的优势，也要说清楚什么情况下继续用 Redis 是合理的。
如果你的应用重度依赖 Redis Stack 的扩展功能，特别是 RediSearch 的全文检索和向量搜索，目前迁移到 Valkey 的代价会比较高，因为对应的开放替代方案还没达到同等成熟度。在这类场景下，等 valkey-search 等项目更稳定之后再迁移是更务实的选择。
如果你是 Redis Enterprise 的付费用户，享有 Redis Ltd. 的商业支持和 SLA 保障，短期内切换会失去这层保障。对于有强合规要求的企业环境，这个因素不能忽略。
如果你的团队对 Redis 有深度的内部知识积累，比如自己维护了大量调优脚本、监控告警规则、运维手册，迁移带来的学习成本和文档重写工作也是真实成本，虽然不大，但值得纳入决策。
—
2026 年的选型建议
站在 2026 年的节点上，这个问题已经没有当初那么模糊了。
对于新项目：几乎没有理由不选 Valkey。BSD-3 协议、Linux Foundation 治理、主流云厂商原生支持、完整的 Redis 命令兼容，没有明显的短板，也没有需要担心的许可证风险。
对于现有 Redis 项目：如果没有重度依赖 Redis Stack 扩展模块，迁移成本低、收益明确（消除许可证合规风险），值得在下一个维护窗口安排进来。
对于依赖 Redis Stack 扩展的场景：保持观望，跟踪 valkey-search 等开放实现的成熟进度，预计 2026 年底到 2027 年初会是一个更合适的迁移时间窗口。
Redis 作为一个技术遗产不会消失，但作为大多数工程师的默认选项，它的位置正在被 Valkey 接管。这不是因为 Valkey 比 Redis 强多少，而是因为 Valkey 在做同样的事情的同时，没有给用户头上加一把许可证的剑。
对于缓存层这种基础设施组件来说，稳定、可预期、没有商业锁定，才是最重要的属性。在这三条上，Valkey 目前的答案更让人安心。
延伸阅读
- LMCache vs vLLM：KV 缓存加速让 LLM 推理快多少？
- Dragonfly vs Redis：内存数据库该怎么选
- umami vs matomo：2026 年自托管网站分析工具深度对比
- Stoplight vs Readme vs Redocly：2026 年 API 文档工具怎么选
- Qdrant 替代品：2026 年主流向量数据库全面对比
Stay updated with our latest AI insights
