每日一题:为什么redis集群的槽是16384

746 阅读2分钟

这个问题redis的主人在github上面有回答:

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.

翻译一下: 原因是:

  • 正常的心跳数据包携带节点的完整配置,可以以幂等方式替换旧配置以更新旧配置。这意味着它们包含原始形式的节点的插槽配置,该节点使用2k空间和16k插槽,但使用65k插槽会使用令人望而却步的8k空间。
  • 同时,由于其他设计权衡,Redis Cluster 不太可能扩展到超过 1000 个主节点。 所以 16k 是在正确的范围内,以确保每个 master 有足够的插槽,最多 1000 个 maters,但这个数量足够小,可以轻松地将插槽配置作为原始位图传播。请注意,在小集群中,位图将难以压缩,因为当 N小时,位图将设置的槽位/N 位占很大比例的位。

简化一下,就是

  1. 槽的信息会作为心跳数据发送,一个槽看作一位的话,那么如果是64k,即心跳信息会占8kb,比较浪费
  2. 一般redis集群节点数量不会超过1000个,超过就会拥堵,所以他不建议节点数量不超过1000个,所以说16384槽位就够用了。
  3. 同时Redis主节点的配置信息中,它负责的哈希槽通过一张bitmap来维护,传输过程中需要对bitmap进行压缩。取节点数为N,那么bitmap压缩率通过slots/N来表示,若果slots太多的话那么压缩率就很低。