本文主要是介绍为什么RedisCluster会设计成16384个槽呢?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
点击上方“朱小厮的博客”,选择“设为星标”
后台回复”加群“加入公众号专属技术群
欢迎跳转到本文的原文链接:https://honeypps.com/backend/why-redis-cluster-use-16384-slots/
Redis Cluster 是Redis的集群实现,内置数据自动分片机制,集群内部将所有的key映射到16384个Slot中,集群中的每个Redis Instance负责其中的一部分的Slot的读写。集群客户端连接集群中任一Redis Instance即可发送命令,当Redis Instance收到自己不负责的Slot的请求时,会将负责请求Key所在Slot的Redis Instance地址返回给客户端,客户端收到后自动将原请求重新发往这个地址,对外部透明。一个Key到底属于哪个Slot由crc16(key) % 16384 决定。
为什么RedisCluster会设计成16384个槽呢?这个问题有点类似于ThreadLocal中的0x61c88647。
对于这个问题,作者给出了解答。原版回答如下图所示,对应的链接地址为:https://github.com/antirez/redis/issues/2576
1.如果槽位为65536,发送心跳信息的消息头达8k,发送的心跳包过于庞大。
在消息头中,最占空间的是 myslots[CLUSTER_SLOTS/8]。当槽位为65536时,这块的大小是: 65536÷8=8kb因为每秒钟,redis节点需要发送一定数量的ping消息作为心跳包,如果槽位为65536,这个ping消息的消息头太大了,浪费带宽。
2.redis的集群主节点数量基本不可能超过1000个。
如上所述,集群节点越多,心跳包的消息体内携带的数据越多。如果节点过1000个,也会导致网络拥堵。因此redis作者,不建议redis cluster节点数量超过1000个。那么,对于节点数在1000以内的redis cluster集群,16384个槽位够用了。没有必要拓展到65536个。
3.槽位越小,节点少的情况下,压缩率高。
Redis主节点的配置信息中,它所负责的哈希槽是通过一张bitmap的形式来保存的,在传输过程中,会对bitmap进行压缩,但是如果bitmap的填充率slots / N很高的话(N表示节点数),bitmap的压缩率就很低。如果节点数很少,而哈希槽数量很多的话,bitmap的压缩率就很低。而16384÷8=2kb,怎么样,神奇不!
综上所述,作者决定取16384个槽,不多不少,刚刚好!
欢迎跳转到本文的原文链接:https://honeypps.com/backend/why-redis-cluster-use-16384-slots/
想知道更多?扫描下面的二维码关注我
【精彩推荐】
-
如何设计出骚气的秒杀系统?
-
滴滴为啥值3600亿,看看它的数据中台就知道了
-
这次终于不再为iptables范迷糊
-
工行分布式数据库选项与大规模容器化实践
朕已阅
这篇关于为什么RedisCluster会设计成16384个槽呢?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!