今天研究redis集群为什么有16384个槽的时候,答案给出了如下的结果
(1)、如果槽位为65536,发送心跳信息的消息头达8k,发送的心跳包过于庞大。如上所述,在消息头中,最占空间的是 myslots[CLUSTER_SLOTS/8]。
当槽位为65536时,这块的大小是:65536÷8÷1024=8kb,因为每秒钟redis节点需要发送一定数量的ping消息作为心跳包,如果槽位为65536,这个ping消息的消息头太大了,浪费带宽。
(2)、redis的集群主节点数量基本不可能超过1000个。如上所述,集群节点越多,心跳包的消息体内携带的数据越多。如果节点过1000个,也会导致网络拥堵。因此不建议redis cluster节点数量超过1000个。对于节点数在1000以内的redis cluster集群,16384个槽位够用了。没有必要拓展到65536个。
(3)、槽位越小,节点少的情况下,压缩比高,Redis主节点的配置信息中,它所负责的哈希槽是通过一张bitmap的形式来保存的,在传输过程中,会对bitmap进行压缩,但是如果bitmap的填充率slots / N很高的话(N表示节点数),bitmap的压缩率就很低。如果节点数很少,而哈希槽数量很多的话,bitmap的压缩率就很低。
我想问的问题就是
一、为什么要发送如上所说的心跳包,这个心跳包发给了谁,有什么作用
二、
集群的键被分割到了16384个槽, 这个槽的算法是:
HASH_SLOT = CRC16(key) & 16384
既然算法固定,怎么确定我的key是被平均的分配到hash槽上面的,如果无法平均的分配到每个节点,那问题就是,分片的作用在哪里,比如我写的每个数据中key都通过这个算法刚好被分配到了一个节点的hash槽里面,那分片模式的意义就没有了啊
三、在这里传输过程是指的什么,是谁发起的传输,又要发送到哪里