為什麼RedisCluster會設計成16384個槽呢?

為什麼RedisCluster會設計成16384個槽呢?這個問題有點類似於ThreadLocal中的0x61c88647。

對於這個問題，作者給出瞭解答。原版回答如下圖所示，對應的連結地址為：

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個槽，不多不少，剛剛好！