目录
问题描述：
对于客户端请求的key，redis是根据公式
HASH_SLOT=CRC16(key) mod 16384，计算出映射到哪个分片上，然后Redis会去相应的节点进行操作。
编辑
原因：
一、消息大小考虑
crc16()一共可以有：
2^16 -1=65535
不同的余数，代表bitmap 有 65535 bit。所以bitmap的大小可以计算为
65535 / 8 (8bit/byte)/1024(1k)=7.99 Kbytes
尽管crc16能得到65535个值，但redis选择16384个slot，是因为16384的消息只占用了2k，而65535则需要8k。
正常的心跳包携带节点的完整配置，可以以幂等方式替换旧配置以更新旧配置。这意味着它们包含原始形式的节点的插槽配置，该节点使用2K的空间和16384个slot，但使用65535的插槽会使用令人望而却步的 8K 的空间。
如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
65k = 8 * 8 (8 bit/byte) * 1024(1k) = 8K bitmap size
为什么要传全量的slot状态？
因为分布式场景，基于状态的设计更合理，状态的传播具有幂等性。
二、集群规模设计考虑
同时，由于其他设计权衡，Redis Cluster 不太可能扩展到超过 1000 个主节点。
集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个
集群设计最多支持1000个分片，16384是相对比较好的选择，需要保证在最大集群规模下，slot均匀分布场景下，每个分片平均分到的slot不至于太小。
所以16384是在正确的范围内，以确保每个 master 有足够的插槽，最多 1000 个 maters，但这个数量足够小，可以轻松地将插槽配置作为原始位图传播。
在小集群中，位图将难以压缩，因为当 N 小时，位图将设置的槽位/N 位占很大比例的位。
为什么不考虑压缩？
集群规模较小的场景下，每个分片负责大量的slot，很难压缩。
简而言之，它是消息大小和主机持有的平均slot数之间权衡的结果。
作者原版回答如下:
The reason is:
- Normal heartbeat packets carry the full configuration of a node, that can be replaced in an idempotent way with the old in order to update an old config. This means they contain the slots configuration for a node, in raw form, that uses 2k of space with16k slots, but would use a prohibitive 8k of space using 65k slots.
- At the same time it is unlikely that Redis Cluster would scale to more than 1000 mater nodes because of other design tradeoffs.
So 16k was in the right range to ensure enough slots per master with a max of 1000 maters, but a small enough number to propagate the slot configuration as a raw bitmap easily. Note that in small clusters the bitmap would be hard to compress because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.
————————————————
学习链接：https://blog.csdn.net/qq_33589510/article/details/118676305
