Redis Cluster 的数据分片机制

Redis Cluster 的数据分片机制，即基于CRC16 算法和16384 个哈希槽（Hash Slot）的分配方法。这是 Redis 分布式架构的核心。

核心思想

Redis Cluster 不使用一致性哈希，而是引入了哈希槽的概念，将整个数据集逻辑上划分为16384（2^14）个槽。每个键通过一个固定的算法计算它属于哪个槽，而每个节点负责管理一部分槽。

这样做的好处是：

• 解耦数据与节点：数据只与槽编号相关，槽与节点的映射可以动态调整。

• 易于管理：集群的扩容、缩容、负载均衡，都转化为槽的迁移操作。

• 计算简单：客户端可以本地计算键的槽位置，直接路由到正确的节点。

键到哈希槽的计算算法

计算分为两步：

1.计算 CRC16 校验和

对键的完整名称（key）进行 CRC16 计算。Redis 使用的 CRC16 多项式是CRC-16-CCITT，即：
X^16 + X^12 + X^5 + 1（初始值 0x0000）。

2.对 16384 取模

slot = CRC16(key) % 16384

结果是一个 0 到 16383 之间的整数，这就是该键的“家”。

键哈希标签（Hash Tags）

为了确保多个相关的键被分配到同一个槽（从而在同一个节点），Redis 支持哈希标签。规则是：

• 如果键中包含{...}模式，则只对{和}之间的子串计算哈希。

• 否则，对整个键计算。

示例：

# 这两个键会被分配到同一个槽，因为只对 "user123" 计算哈希 SET user:{user123}:profile "Alice" SET user:{user123}:session "abc123" # 计算方式：slot = CRC16("user123") % 16384

槽到节点的映射

集群启动时或经过重配置后，每个主节点会负责一个或多个槽的范围。例如：

• 节点 A：负责槽 0 - 5500

• 节点 B：负责槽 5501 - 11000

• 节点 C：负责槽 11001 - 16383

这个映射关系被称为集群配置，它由所有节点共享。客户端在启动时会获取一份副本，从而可以直接将命令发送到正确的节点。

客户端请求路由

1. 客户端本地计算槽：客户端根据上述算法计算出键对应的槽号。

2. 检查本地缓存：客户端查看本地缓存的“槽-节点”映射表。

3. 发送命令：

   • 如果映射正确，直接发送命令到对应节点。

   • 如果映射不正确（例如集群已迁移），目标节点会返回MOVED 错误并附带正确的节点地址，客户端更新映射并重试。

4. ASK 重定向：在槽迁移过程中，如果请求的键已被迁移到新节点，旧节点会返回ASK 重定向，客户端临时向新节点发送命令。

为什么是 16384 个槽？

作者 Antirez 在 GitHub 讨论 中解释过：

1. 内存与心跳包大小：集群中每个节点需要定期广播它负责的槽位图（16384 位 = 2KB）。如果槽数太多（如 65536），心跳包会过大（8KB），浪费网络带宽。

2. 足够的分片：16384 个槽对于最多 ~1000 个节点的集群已经足够，而 Redis Cluster 设计上不建议超过 1000 个节点。

3. CRC16 分布性：CRC16 输出 65536 个可能值，取模 16384 后冲突率在可接受范围。

槽迁移与重新分片

当需要扩容或缩容时，管理员可以使用redis-cli --cluster reshard命令将槽从一个节点迁移到另一个节点。迁移过程：

• 标记槽为“迁移中”状态。

• 迁移槽内的键数据。

• 更新集群配置，将槽的所有权转移给新节点。

迁移期间，集群仍可正常处理请求（通过 MOVED/ASK 重定向）。

总结表