Codis vs redis 集群

我们将跳过表面的功能列表，直接进入源码和架构的核心深水区。

Slots 分布

Codis 和 Redis Cluster 最本质的区别在于元数据（Slots 分布）的管理方式。这决定了它们在源码层面的差异。

Codis：Centralized） Codis 中，有一个中心管理节点——ZooKeeper。 Codis 的源码（主要是 Go 语言编写的 codis-proxy 和 codis-dashboard），Topom（Topology Manager）是核心结构。Dashboard 负责把 Slot 的映射关系写入 ZK。 codis-proxy 启动时，会通过 Watch 机制监听 ZK 的变化。这意味着 Proxy 本身是“无状态”的，它的内存里缓存了一份从 ZK 拉取下来的路由表（Slots Map）。

• 源码细节：在 pkg/proxy/router/router.go 中，Proxy 维护了一个 Slot 数组（默认 1024 个）。当请求到来时，Proxy 计算 Hash -> 查数组 -> 拿到后端 Redis 地址 -> 转发。这就好比公司里有一个前台，所有人都得问她“厕所在哪”，她手里有一张老板（ZK）给的最新的地图。

Redis Cluster：邻里八卦（Gossip / P2P） Redis Cluster 没有上帝，只有邻居。 在 Redis 源码 cluster.c 中，核心是 Gossip 协议。每个节点都维护了一个 clusterNode 结构体，里面包含了一个巨大的 Bitmap（myself->slots），标记自己负责哪些 Slot（总共 16384 个）。

• 源码细节：Redis Cluster 依靠 clusterCron 函数每秒随机挑选几个节点发送 PING 包。这个包的结构体 clusterMsg 非常庞大，里面不仅有发送者的状态，还捎带了“我知道的其他节点”的信息。这就像村口的大妈，每个人都知道一点消息，通过互相聊天，最终全村（集群）都知道了谁家（节点）负责哪块地（Slot）。
• 2022年的痛点：在 2022 年大规模集群场景下，Gossip 协议的带宽消耗成为了一个明显的瓶颈（这也催生了 Redis 7.0 对 Gossip 的优化），而 Codis 的 ZK 模式在超大规模下反而显得元数据更新更可控。

2. I/O 路径与“聪明”的代价

Codis：把复杂留给自己（Proxy-based） Codis 的设计哲学是“对客户端透明”。 在 codis-proxy 的源码中，使用了大量的 Go Channel 和 Goroutine 来处理并发。

• Pipeline 的处理：这是 Proxy 模式最难的地方。Codis 需要解析客户端发来的整个 Pipeline 请求流，将其拆解，计算每个命令的 Key 属于哪个后端 Server，然后分组转发。等后端都返回了，Proxy 再按顺序组装回去还给客户端。
• 源码细节：在 pkg/proxy/redis/decoder 中，Codis 自己实现了一套极其高效的 RESP 协议解析器。它本质上是一个“中间人攻击者”，它欺骗 Client 说“我就是 Redis”，然后转身去后端真正的 Redis 那里干活。

Redis Cluster：把麻烦甩给客户端（Smart Client） Redis Cluster 的 Server 端代码极其“傲慢”。 当一个请求发给 Redis 节点，节点在 processCommand 中会检查 key 所在的 Slot 是否由自己负责。如果不是？

• 源码细节：它不会帮你转发，而是直接构建一个 -MOVED 3999 192.168.0.2:6379 的错误返回。
• 这就要求 2022 年的主流客户端（如 Java 的 Lettuce/Jedis，Go 的 go-redis）必须非常“聪明”。客户端内部必须缓存一份 Slot 映射表（SlotCache）。收到 -MOVED 错误时，客户端不仅要重发请求，还要更新自己的本地缓存。这使得 Client 的代码复杂度远高于 Codis 模式。

3. 数据迁移：最精彩的博弈

这是两者差异最巨大的地方，也是运维最头疼的环节。

Codis：侵入式修改（codis-server） 你可能不知道，Codis 的后端 Redis 并不是官方 Redis，而是被修改过的 codis-server。 Codis 团队在 Redis 源码中硬塞了一组自定义命令，最核心的是 SLOTSMGRTTAGSLOT。

• 迁移逻辑：Codis 的迁移是由外部工具（Dashboard/Fe）发起的。它通过 Proxy 甚至直接向 Server 发送这个命令，强制 Server 把原本属于自己的数据“吐”给新节点。
• 大 Key 问题：Codis 对大 Key（Big Key）的迁移做了很多优化（比如分批次迁移 Hash 字段），这些逻辑被写在了 Go 语言的 Dashboard 代码中，配合 Server 端的修改，使得 Codis 的扩容在早期版本比 Redis Cluster 平滑得多。

Redis Cluster：原生状态机（MIGRATE） Redis Cluster 的迁移完全依赖原生的 MIGRATE 命令和两个特殊状态：IMPORTING 和 MIGRATING。

• 源码细节：当你用 redis-cli --cluster reshard 时，它实际上是在源节点标记 MIGRATING，在目标节点标记 IMPORTING。
• ASK 重定向：这是最精妙的设计。在迁移过程中，数据可能一半在源节点，一半在目标节点。如果客户端访问源节点，源节点发现 Key 正在迁移但还没走，就处理；如果 Key 已经走了，它返回 -ASK。客户端收到 ASK 后，必须先向目标节点发送 ASKING 命令（打个招呼，否则目标节点会拒绝服务非自己 Slot 的请求），然后再发送正式命令。
• 阻塞风险：在 Redis 4.0 之前，MIGRATE 是同步阻塞的，迁一个大 Key 整个 Redis 就卡死。虽然 2022 年我们大多用 Redis 6.0+（支持 MIGRATE ... ASYNC），但 Cluster 的迁移机制依然比 Codis 更容易导致抖动。

4. 2022 年的运维现实：时代的眼泪

如果将时间定格在 2022 年，这场战争的胜负已定。

Codis 的致命伤：版本停滞

• 源码层面：Codis 的 codis-server 大多基于 Redis 3.2 分支修改。虽然你可以强行用原生 Redis 替换后端，但会失去部分高级迁移特性。
• 新特性缺失：2022 年，Redis 6.0 的多线程 I/O、ACL（访问控制列表）、TLS 加密已经是标配。Codis Proxy 是用 Go 写的，虽然天生支持多线程，但它不支持 Redis 6 的 ACL 协议透传，也不支持 TLS 到后端的原生链路。这意味着在一个追求零信任安全的现代云环境中，Codis 显得格格不入。

Redis Cluster 的胜利：标准化

• 去中心化的胜利：虽然 Gossip 协议有广播风暴的风险，但 Redis 7.0 (2022年发布) 对此做了大量优化（Sharded Pub/Sub）。
• 云厂商的选择：你可能会发现阿里云、腾讯云的 Redis 集群版好像既不是标准的 Cluster 也不是 Codis？实际上，云厂商通常采用 “Proxy + Redis Cluster” 的混合架构。底层由 Redis Cluster 负责数据分片和故障转移（利用了官方的成熟代码），上层再架设一层自研的高性能 Proxy（类似 Codis Proxy 的角色），对外屏蔽 MOVED 错误，提供统一入口。这变相证明了：Codis 的 Proxy 思想是对的，但 Codis 的实现已经老了；而 Redis Cluster 的底层分片机制成为了工业标准。

总结

在源码级别，Codis 是一个精密的路由器，配合了一群被“改造过”的 Redis 节点，依靠 ZK 这个大脑指挥；而 Redis Cluster 是一群高智商的个体，通过八卦协议自组织，依靠客户端的配合来完成工作。