爲什麼RedisCluster會設計成16384個槽?

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個槽,不多不少,剛剛好!

發佈了159 篇原創文章 · 獲贊 28 · 訪問量 6萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章