龙空技术网

Redis官方解答:为啥Redis Cluster设计成16384个槽?

秃头JAVA 507

前言:

此时看官们对“redis集群16384”大约比较关注,各位老铁们都想要学习一些“redis集群16384”的相关知识。那么小编也在网上搜集了一些关于“redis集群16384””的相关资讯,希望小伙伴们能喜欢,姐妹们快快来了解一下吧!

消息大小考虑

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数之间权衡的结果。

标签: #redis集群16384