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
这个映射关系被称为 集群配置，它由所有节点共享。客户端在启动时会获取一份副本，从而可以直接将命令发送到正确的节点。
客户端请求路由
-
客户端本地计算槽：客户端根据上述算法计算出键对应的槽号。
-
检查本地缓存：客户端查看本地缓存的"槽-节点"映射表。
-
发送命令：
-
如果映射正确，直接发送命令到对应节点。
-
如果映射不正确（例如集群已迁移），目标节点会返回 MOVED 错误 并附带正确的节点地址，客户端更新映射并重试。
-
-
ASK 重定向 ：在槽迁移过程中，如果请求的键已被迁移到新节点，旧节点会返回 ASK 重定向，客户端临时向新节点发送命令。
为什么是 16384 个槽？
作者 Antirez 在 GitHub 讨论 中解释过：
-
内存与心跳包大小：集群中每个节点需要定期广播它负责的槽位图（16384 位 = 2KB）。如果槽数太多（如 65536），心跳包会过大（8KB），浪费网络带宽。
-
足够的分片：16384 个槽对于最多 ~1000 个节点的集群已经足够，而 Redis Cluster 设计上不建议超过 1000 个节点。
-
CRC16 分布性：CRC16 输出 65536 个可能值，取模 16384 后冲突率在可接受范围。
槽迁移与重新分片
当需要扩容或缩容时，管理员可以使用 redis-cli --cluster reshard 命令将槽从一个节点迁移到另一个节点。迁移过程：
-
标记槽为"迁移中"状态。
-
迁移槽内的键数据。
-
更新集群配置，将槽的所有权转移给新节点。
迁移期间，集群仍可正常处理请求（通过 MOVED/ASK 重定向）。
总结表
| 组件 | 说明 |
|---|---|
| 哈希槽总数 | 16384 个固定槽 |
| 哈希算法 | CRC16(key) % 16384 |
| 哈希标签 | {...} 确保相关键同槽 |
| 槽分配 | 每个主节点负责一部分槽范围 |
| 客户端路由 | 本地计算槽，根据缓存映射发送，支持 MOVED/ASK 重定向 |
| 重分片 | 槽可以在节点间迁移，支持在线扩容缩容 |