Redis与Valkey：许可、兼容边界和并发性能

如果现有Redis负载主要使用常见命令，且团队需要宽松的BSD许可，Linux Foundation支持的Valkey项目值得列入迁移候选。是否真正切换，要同时看许可证义务、应用依赖和生产配置下的性能；能连上服务端，只完成了兼容性检查的一部分。

公开跑分也不能替团队作决定。并发连接数、读写比例和持久化设置都会影响结果；现有业务如果写入较多、连接数不高，不能只凭某个高并发吞吐数字预期迁移收益。

先按版本和使用方式核对许可证

Redis许可说明列明：Redis Open Source 8及以后可选择RSALv2、SSPLv1或AGPLv3；Redis OSS 7.2及更早版本使用BSD三条款许可，Redis Community Edition 7.4至7.8则提供RSALv2或SSPLv1。搜索、JSON、时间序列和概率数据相关能力也已纳入新版的许可框架。因此，评估许可时应写明正在运行的版本，以及计划采用的目标版本。

这些许可允许的用途和附带义务不同。RSALv2对软件商业化及向第三方提供其功能的托管服务设有限制；SSPLv1涉及将软件作为服务提供时公开相关源码的要求；AGPLv3属于获OSI认可的开源许可，也有源码义务。Valkey采用的BSD许可较宽松，但服务端的许可结论不能直接套用到客户端库、外部模块或托管平台的服务条款。

对于只在内部运行未修改服务端的团队，许可审查的重点与修改代码并对外提供服务的团队不同。迁移前应让负责许可审查的人按实际部署、分发和服务方式判断义务，再把判断结果纳入技术选型。项目由基金会支持关乎治理和维护路径；具体使用条件仍由适用的许可文本决定。

兼容性要分协议、数据、模块和客户端

Valkey迁移文档说明，Valkey支持RESP2与RESP3，现有Redis客户端库可以连接；对Redis OSS 7.2及更早版本，它提供兼容的配置、RDB和AOF迁移路径，而Redis Community Edition 7.4及以后生成的数据文件不能直接按该路径导入。文档还列出快照、复制和逐键迁移等方式，但具体选择取决于源端版本、停机窗口与写入是否持续发生。

协议连通只能证明连接和已执行的请求成功，不能证明整套应用行为一致。迁移回归应从命令日志与应用代码中找出实际调用，覆盖脚本、事务、发布订阅、ACL、集群重定向和运维命令，并观察返回值、错误处理与超时。框架和监控组件发出的命令也要纳入，因为它们可能不出现在业务代码的显式调用中。

模块需要独立盘点：列出每个模块的名称、版本、使用的命令及数据类型，再验证目标环境是否提供等价能力。即使某个模块可加载，也应检查已有数据能否读取、索引是否需要重建，以及应用是否依赖特定返回格式。对搜索、JSON或时间序列等能力尤其不能把基础协议兼容当成完整功能兼容。

客户端还可能依据服务端版本字段选择代码路径。Valkey为向后兼容，在INFO中保留旧的redis_version值；如果驱动或监控规则依赖这个字段识别服务端，应检查其识别逻辑和实际请求行为。完成连接测试后，再跑应用回归，才能发现这种表面可用、运行时却出现分歧的情况。

公开测试显示优势随负载翻转

乌默奥大学一项重复三轮的对比研究测试了Redis 7.2.7与Valkey 8.0.2：读写各半、200个并发连接时，Valkey吞吐比Redis低15%；读取占95%、1500个并发连接时，Valkey比Redis高20%。测试使用Kubernetes中的单实例，关闭持久化，也没有使用流水线。因此，这些数字描述的是该版本组合和测试条件，不能用于给Redis 8的性能排名。

同一研究中的吞吐曲线比单个峰值更有用。读写各半时，Redis在多数低至中等并发测试点领先，Valkey到更高并发才小幅反超；读多的负载则在高并发区间出现更明显的Valkey优势。若业务的连接数主要落在前一段区间，引用后一段的最大领先幅度，就会把与自身负载不相符的结果带入决策。

吞吐也不是唯一的验收指标。研究同时测量了延迟，而面向在线请求的缓存还应关注尾延迟、CPU和内存占用。生产环境若启用AOF、生成RDB快照或部署复制，测量条件便与该研究不同；这些开销应进入自己的压测，而不应由关闭持久化的结果推算。