分叉与兼容性

Difficulty: Advanced
Status: Stable
Last reviewed: 2026年8月

This content is not available in your language yet.

分叉后的第一原则不是“所有名字都换掉”，而是区分兼容层级：客户端线上的协议兼容、持久化与数据语义兼容，以及构建和运维生态兼容。Valkey 的源码和 README 同时保留新身份与 Redis 兼容线索，正是这个取舍的结果。

先给答案：兼容性不是“能不能启动”，而是多个生态边界同时不破裂

Valkey 的兼容性至少有三层：协议与命令行为兼容，配置和持久化格式兼容，客户端、模块和运维工具生态兼容。版本宏和分叉标识只是代码层面的信号，不能自动证明所有行为都相同。

分叉项目最值得读的不是“哪里改了名字”，而是哪些共同假设被保留、哪些假设因并发或治理方向改变而被替换。判断是否兼容，要拿具体客户端、命令语义、持久化文件和模块 ABI 做验证，不能把源码目录相似当作行为等价。

三层兼容模型

协议层     RESP、命令参数、错误语义、URI
数据层     RDB/AOF 读写、复制与集群交互
工程层     redis-server 名称、Redis/Valkey 链接、构建脚本

版本宏为什么双轨存在

src/version.h 同时定义 VALKEY_VERSION 和 REDIS_VERSION 7.2.4。前者用于产品版本与发布身份，后者为仍需判断 Redis 兼容行为的代码保留基线。单纯把所有 REDIS_* 符号机械替换成 VALKEY_*，会破坏模块 API、脚本和已有构建逻辑。

工程生态的兼容

README 仍说明可通过 Redis 命名符号启动，支持 Redis/Valkey URI、TLS 和 RDMA 等构建与连接入口。这种兼容不是“品牌没有变化”，而是降低迁移成本：老的脚本、容器入口和客户端配置不必在同一天全部改名。

old tooling/config
      | redis-server name / redis:// URI
      v
Valkey process
      | VALKEY_VERSION = new identity
      | REDIS_VERSION  = compatibility reference

为什么不承诺无限兼容

兼容层越厚，维护成本越高。Valkey 可以保持线协议和核心数据语义，却不应假设所有 Redis 私有实现、模块 ABI、未文档化错误文本都永久稳定。src/version.h 的双轨更像“有意识的迁移边界”，不是无限期的别名承诺。

边界与坑

客户端看到能连通，不等于所有命令、模块和集群拓扑行为完全一致。
依赖 Redis 私有符号或未文档化内存布局的模块，不能只靠 RESP 兼容判断可迁移。
版本比较必须明确比较的是 Valkey 产品版本还是 Redis 兼容基线，不能混用。

可迁移知识

分叉项目应把兼容性写成矩阵，而不是一句“兼容”。对每层列出保持项、变化项和测试证据；在代码中保留兼容宏或适配器，把迁移成本集中在边界处。

面试锚点：为什么 Valkey 还保留 Redis 版本宏？协议兼容、数据兼容和 ABI 兼容有什么区别？