为什么 Redis Cluster 的 Hash Slot 是 16384？

一、Redis Cluster 的 Hash Slot 算法是怎么实现的？

Redis Cluster 的 Hash Slot 算法是通过对键进行哈希计算，将键映射到不同的哈希槽位的过程来实现的。

Redis Cluster 的 Hash Slot 算法实现了数据的分片和路由，保证了数据在集群中的均匀分布和高效访问。同时，哈希槽的固定数量和节点间的数据迁移机制提供了容错性和可扩展性。

1.1 Redis Cluster Hash Slot 算法实现步骤

1.2 Redis Cluster 处理完整流程（带Hash Slot 算法步骤）

graph TD;
    A[客户端] -->|发送命令| B[Redis Cluster];
    B -->|计算键的哈希值| C[哈希槽计算,取模运算,得到槽位编号];
    C -->|确定负责的节点| D[槽位映射表];
    D -->|路由命令| E[负责的节点];
    E -->|执行命令| F[Redis操作];
    F -->|返回结果| A;

二、Hash 算法的值是65536个，为什么选择16384呢？

对于客户端请求过来键值 key，哈希槽=CRC16(key) % 16384，CRC16 算法产生哈希值 16bit，按道理该算法可以产生 2^16=65536 个值，为什么不用 65536，用 16384（2^14）呢？

2.1 作者的原始回答

下面是作者的原始回答（原始回答链接）：

翻译一下作者的回答就是

原因是：

1、正常的心跳数据包携带节点的完整配置，可以以幂等方式替换旧配置以更新旧配置。这意味着它们以原始形式包含节点的插槽配置，该节点使用携带有 16k 插槽的 使用 2k 空间，但使用携带有 65k 插槽时会达到令人望而却步的 8k 空间。

2、同时，由于其他设计权衡，Redis 集群不太可能扩展到超过 1000 个主节点。

因此，16k 处于正确的范围内，可以确保每个主机有足够的插槽，最多 1000 个主机，但数量足够小，可以轻松地将插槽配置作为原始位图传播。请注意，在小簇中，位图将难以压缩，因为当 N 很小时，位图将具有插槽/N 位设置，这是位设置的很大百分比。

2.2 扩展思考和解析

2.2.1 先解析一下作者回答的2k空间和8K空间

Redis 中使用 unsigned char slots[REDIS_CLUSTER_SLOTS/8] 数组来表示每个实例节点所负责的哈希槽位。

Redis每个实例节点上都保存对应有哪些slots，它是一个unsignedcharslots[REDIS_CLUSTER_SLOTS/8]类型。

• 8K：在redis节点发送心跳包时需要把所有槽放到这个心跳包里，如果slots数量65536，占空间=65536/8(一个字节8bit)/1024(1024个字节1kB)=8kB

• 2k:如果使用slots数量16384，所占空间=16384/8(每个字节8bit)/1024(1024个字节1kB)=2kB

有了上面的2K和8K解释，再来读作者回答就很容易理解了；如果还有不清楚的，可以阅读下面的详细解析

在 Redis 集群中，节点之间通过发送心跳数据包来进行通信和协调。这些心跳数据包通常携带节点的完整配置信息，用于更新其他节点的视图。在正常情况下，心跳数据包以幂等的方式替换旧配置，以实现配置的更新。

在 Redis 集群中，每个节点负责管理一部分连续的哈希槽位，这些槽位构成了整个数据集的分片。每个节点都需要知道其他节点的槽位配置，以便在进行数据路由和数据迁移时做出正确的决策。

当心跳数据包携带节点的完整配置时，它们通常以原始形式包含节点的槽位配置信息。这意味着对于一个节点来说，如果它负责的槽位数量较少（例如 16k 插槽），那么携带这些槽位配置的心跳数据包将使用较少的空间（例如 2k）。这是因为心跳数据包只需要包含槽位的信息。

然而，当一个节点负责的槽位数量增加到很大（例如 65k 插槽）时，携带这些槽位配置的心跳数据包将会变得非常大，占用的空间将会增加。在这种情况下，心跳数据包可能会占用较大的空间（例如 8k），这可能会导致网络传输和处理开销的增加，从而引起性能上的问题。

因此，当节点负责的槽位数量增加到令人望而却步的程度时，携带完整插槽配置的心跳数据包可能会变得不可行或不切实际。

2.2.2 为什么 Redis 集群不太可能扩展到超过 1000 个主节点？

Redis 集群在设计上并不鼓励扩展到超过 1000 个主节点的规模。这是因为 Redis 集群的设计目标是为了提供高可用性和数据分片。

而在实践中，较大规模的 Redis 集群可能会遇到一些挑战和限制，包括：

graph LR
A(超过1000的坏处) ---> B(网络通信和协调成本)
A(超过1000的坏处) ---> C(配置管理复杂性)
A(超过1000的坏处) ---> D(数据迁移和重新分片成本)
A(超过1000的坏处) ---> E(集群管理的复杂性)

style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px
style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px
style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px
style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

• 网络通信和协调成本：随着节点数量的增加，集群内部的网络通信和协调成本会增加。节点之间需要进行心跳检测、数据同步、故障转移等操作，这些操作会导致更多的网络开销和延迟。

• 配置管理复杂性：管理超过 1000 个主节点的配置将变得复杂且困难。节点的增加、删除、配置变更等操作将变得更加复杂和耗时，容易出现人为错误。

• 数据迁移和重新分片成本：当节点数量增加时，数据迁移和重新分片的成本也会增加。在 Redis 集群中，当节点数量变化时，需要对槽位进行重新分配和数据迁移以保持数据的均衡分布。这些操作会导致集群在迁移期间的性能下降，并且可能需要较长的时间来完成。

• 集群管理的复杂性：超过 1000 个主节点的集群将变得非常复杂，需要更多的管理和监控工具来维护和监控集群的状态和性能。