版本发布不是打 tag，发布后才是分叉
2024 年春天，Valkey 从 Redis 7.2.4 这个 tag 上分叉出去。光看版本号，两边都是 7.2.4，下载下来连 redis-cli 都能连，很多团队第一反应是“替代品来了”。但版本发布不是一个瞬间，而是一个持续动作：fork 之后 Redis 和 Valkey 会在各自分支里修 bug、合不同 PR，面对同一个 CVE 也可能给出不同修复方案。版本号能证明代码曾经同源，不能证明以后的补丁和演进路线也同源。
三个真实差异，别等上线才发现
Redis 官方从 7.4 开始不再用原来的 3-Clause BSD 授权，改成 RSALv2 和 SSPLv1 双许可证；Valkey 守的是 fork 当天留下的 BSD-3-Clause。如果你只做版本号审计，看到 Redis 7.2.4 是 BSD 就把整条升级链放行，那后续升级到 7.4 之后的版本会发现条款完全不同。授权变更往往不写在 release notes 的第一屏，但它比性能优化更直接决定你能不能部署。
Valkey 的二进制叫 valkey-server，Redis 的二进制叫 redis-server。systemd 服务名、日志轮转路径、配置目录在安装包里都不同。你原来用 /etc/redis/redis.conf 管理配置的话，直接指向 Valkey 的目录当然可以把参数带过去，但服务启动脚本、日志采集权限和打包升级逻辑都要跟着改。
第三个差异是发布主体的变化。Valkey 由 Linux Foundation 在维护，Redis 依然走它自己的版本节奏。两边的安全公告渠道不同，CVE 修复时间也不会自动同步。版本号相同的两个产品，后续得到的不仅是不同补丁，而是不同命运的软件。
这种同源版本，要拿什么做比较
跑 benchmark 是最没意思的对比，因为两边在 7.2.4 那个 commit 的代码差距确实很小，跑分只能说明编译参数和机器状态。真正要对比的是四层：
- 协议层：PING、SET、GET、PUB/SUB、Stream，这些常用命令按真实流量跑一遍。
- 数据层：RDB 和 AOF 能不能互读，主从切换后新库会不会产生旧版本读不了的文件。
- 权限层：ACL 规则格式是否兼容，requirepass 之外的细粒度账号有没有因为默认配置改变而失效。
- 管理层：INFO、SLOWLOG、LATENCY 和 MONITOR 输出里的字段名、单位、顺序是否一致，不然监控面板会静默变白。
只测 GET/SET 然后宣布兼容，比不测还危险。因为在 Redis Cluster 场景里，很多命令带路由信息，跨 slot 的 MULTI/EXEC 和 Lua 脚本最容易踩坑。
版本号只是起点，值钱的是升级权
今天每次看到软件说发布新版本，我都会先问：这个版本由谁发布、对谁发布、修了什么 bug。一旦软件换了维护主体，即使 API 100% 兼容，发布策略也会出现裂缝。一个大公司可能为内部场景提前修掉一个 bug，而普通用户要等下一次公开 release；另一个社区可能优先处理自己生态里被反复报告的 CVE。你选的不是 7.2.4 或 8.0，你选的是未来把安全更新递给你的那条管道。
我的观点可能不太好听：Redis 7.2.4 和 Valkey 7.2.4 是两条版本线，但它们的共同作者只会越来越少。对于已经在跑 Redis 7.2 的生产环境，不要因为“Valkey 7.2.4 完全兼容”就盲目迁移；对于新项目，也不要因为有 Redis 7.2.4 这个旧版本就假装未来不存在。真正要做的是冻结服务名、梳理 config、挖出不兼容点，然后亲自跑一次小流量割接，再看补丁通道是否值得信任。