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