消息大小考虑
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 的空间。
65k = 8 * 8 (8 bit/byte) * 1024(1k) = 8K bitmap size
为什么要传全量的slot状态？
因为分布式场景，基于状态的设计更合理，状态的传播具有幂等性。
集群规模设计考虑
同时，由于其他设计权衡，Redis Cluster 不太可能扩展到超过 1000 个主节点。集群设计最多支持1000个分片，16384是相对比较好的选择，需要保证在最大集群规模下，slot均匀分布场景下，每个分片平均分到的slot不至于太小。
所以16384是在正确的范围内，以确保每个 master 有足够的插槽，最多 1000 个 maters，但这个数量足够小，可以轻松地将插槽配置作为原始位图传播。
在小集群中，位图将难以压缩，因为当 N 小时，位图将设置的槽位/N 位占很大比例的位。
为什么不考虑压缩？
集群规模较小的场景下，每个分片负责大量的slot，很难压缩。
简而言之，它是消息大小和主机持有的平均slot数之间权衡的结果。
参考
