为什么Redis集群的最大槽数是16384个?
大家好,我是哪吒。
上一篇分享了# 一次线上事故,导致公司损失400万,完成了Redis避免使用大Key的学习和理解。
一、Redis集群是什么?
由于数据量过大,单个master复制集难以承担,因此需要多个master进行承担工作,每个master存储部分数据,这就是Redis集群。
Redis集群包含多个master,一个master对应多个slave,由于集群自带故障转移机制,因此Redis集群不用再使用哨兵sentinel功能。
Redis Cluster是Redis3.0引入的一种无中心化的集群,客户端可以向任何一个节点通信,不同节点间的数据不互通,Redis Cluster将数据的key通过将CRC16算法的结果取模16383后,分给16384个slot槽,集群的每个节点负责一部分hash槽,节点只负责管理映射到这个槽的KV数据,对于不是当前槽的KV数据,会向客户端发送一个MOVED,表示需要客户端重新重定向到其它节点。
使用Redis集群时,我们将需要存储的数据分配到多台Redis服务器上,称为分片。
数据如何分片?
对key进行CRC16(key)算法处理并通过对总分片数量取模,然后使用确定性哈希函数,将指定的key多次映射到同一个分片上。这种模式下,在进行服务器扩容的时候,不会影响集群的使用状态。
Redis集群不保证强一致性,在特定条件下,Redis集群可能会丢掉一些命令。
二、slot槽位映射的方式
1、哈希取余分区
哈希取余分区的优点是分配均匀,使用hash(key)/3的形式让固定的一部分请求存入指定的master,每台master处理一部分数据,起到了负载均衡的效果。
哈希取余分区最大的缺点就是不方便扩容,当需要扩容时,映射关系需要进行重新计算。
2、一致性哈希算法
(1)一致性哈希算法是什么?
一致性哈希算法在1997年由麻省理工学院提出,是一种特殊的哈希算法,目的是解决分布式缓存的问题。 在移除或者添加一个服务器时,能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。一致性哈希解决了简单哈希算法在分布式哈希表( Distributed Hash Table,DHT) 中存在的动态伸缩等问题。
一致性哈希算法将整个哈希值空间映射成一个虚拟的圆环,整个哈希空间的取值范围为0~2^32^-1
,整个空间按顺时针方向组织,0~2^32^-1
在零点中方向重合。
接下来使用如下算法对服务请求进行映射,将服务请求使用哈希算法算出对应的hash值,然后根据hash值的位置沿圆环顺时针查找,第一台遇到的服务器就是所对应的处理请求服务器。
当增加一台新的服务器,受影响的数据仅仅是新添加的服务器到其环空间中前一台的服务器(也就是顺着逆时针方向遇到的第一台服务器)之间的数据,其他都不会受到影响。
综上所述,一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。
(2)一致性哈希算法的优点
- 可扩展性
- 更好的适应数据的快速增长,当某个分片存储数据过多时,可以将其一分为二,不需要对全部的数据进行重新hash计算和划分。
(3)一致性哈希算法的缺点
当服务节点太少时,容易造成数据倾斜,分配不均。
大量的缓存数据集中到了一台或者几台服务节点上,称为数据倾斜。
三、为什么Redis集群的最大槽数是16384个?
2^14^=16384、2^16^=65536。
如果槽位是65536个,发送心跳信息的消息头是65536/8/1024 = 8k。
如果槽位是16384个,发送心跳信息的消息头是16384/8/1024 = 2k。
因为Redis每秒都会发送一定数量的心跳包,如果消息头是8k,未免有些太大了,浪费网络资源。
上面提过,Redis的集群主节点数量一般不会超过1000个。集群中节点越多,心跳包的消息体内的数据就越多,如果节点过多,也会造成网络拥堵。因此Redis的作者Salvatore Sanfilippo
不建议Redis Cluster的节点超过1000个,对于节点数在1000个以内的Redis Cluster,16384个槽位完全够用。
Redis主节点的哈希槽信息是通过bitmap存储的,在传输过程中,会对bitmap进行压缩,bitmap的填充率越低,压缩率越高。
bitmap 填充率 = slots / N (N表示节点数)
。
也就是说slots越小,填充率就会越小,压缩率就会越高,传输效率就会越高。
转载自:https://juejin.cn/post/7216293600483983419