消息大小考虑

crc16()一共可以有：

2^16 -1=65535

  

 

  
1
 

不同的余数，代表bitmap 有 65535 bit。所以bitmap的大小可以计算为

65535 / 8 (8bit/byte)/1024(1k)=7.99 Kbytes

  

 

  
1
 

尽管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

  

 

  
1
 

为什么要传全量的slot状态？

因为分布式场景，基于状态的设计更合理，状态的传播具有幂等性。

集群规模设计考虑

同时，由于其他设计权衡，Redis Cluster 不太可能扩展到超过 1000 个主节点。集群设计最多支持1000个分片，16384是相对比较好的选择，需要保证在最大集群规模下，slot均匀分布场景下，每个分片平均分到的slot不至于太小。
所以16384是在正确的范围内，以确保每个 master 有足够的插槽，最多 1000 个 maters，但这个数量足够小，可以轻松地将插槽配置作为原始位图传播。

在小集群中，位图将难以压缩，因为当 N 小时，位图将设置的槽位/N 位占很大比例的位。

为什么不考虑压缩？

集群规模较小的场景下，每个分片负责大量的slot，很难压缩。

简而言之，它是消息大小和主机持有的平均slot数之间权衡的结果。

参考

• https://github.com/redis/redis/issues/2576

文章来源: javaedge.blog.csdn.net，作者：JavaEdge.，版权归原作者所有，如需转载，请联系作者。

原文链接：javaedge.blog.csdn.net/article/details/118676305