? ? ? ? 上篇文章我們講解了Redis Cluster的狀態監測與恢復過程，這篇文章我們來進行Redis Cluster內容的收尾，將其擴容和縮容的過程進行講解，并分析RedisCluster的優缺點。

擴容和縮容

? ? ? ? 當集群中出現容量限制或者其他一些原因需要擴容時，Reids Cluster提供了比較優雅的集群擴容方案：

? ? ? ? （1）首先將新節點加入到集群中，可以通過在集群中熱河一個客戶端執行Cluster meet新節點ip：端口，或者通過redis-trib add node添加，新添加的節點默認在集群中都是主節點。

? ? ? ? （2）數據的遷移。遷移數據的大致流程是，首先需要確定哪些槽需要被遷移到目標節點，然后獲取槽中key，將槽中的key全部遷移到目標節點，然后向集群所有主節點廣播槽（數據）全部遷移到了目標節點。

? ? ? ? 縮容的大致過程與擴容一致，需要判斷下線的節點是否是主節點，以及主節點上是否有槽。若主節點上有槽，需要將槽遷移到集群中的其他主節點，槽遷移完成之后，需要向其他節點廣播該節點準備下線。最后需要將該下線主節點的從節點指向其他主節點（最好是先將從節點下線）。

為什么Redis Cluster的Hash Slot是16384？

? ? ? ? 在Redis節點發送心跳包時需要把所有的槽放到這個心跳包里，以便讓節點知道當前集群信息，16384 = 16K，在發送心跳包時使用char進行bitmap壓縮后是2K，也就是說用2K的空間創建了16K的槽數。

? ? ? ? 雖然說用CRC16算法最多可以分配65535個槽位，65535 = 65K，壓縮后就是8K，也就是說需要8K的心跳包，作者認為這樣不太值的；并且一般情況下一個Redis集群不會有超過1000個Master節點，所以16K的槽位是比較合適的選擇。

為什么Redis Cluster中不建議使用發布訂閱呢？

? ? ? ? 在集群模式下，所有的publish命令都會向所有節點（包括從節點）進行廣播，造成每條publish數據都會在集群內所有節點傳播一次，加重了帶寬負擔，對于在有大量節點的集群中頻繁使用pub，會嚴重消耗帶寬，不建議使用。（雖然官網上說有時候可以使用布隆過濾器或其他算法進行優化）。

Redis Cluster的優缺點總結：

? ? ? ? 優點：

? ? ? ? （1）無中心架構。

? ? ? ? （2）數據按照Slot存儲分布在多個節點，節點間數據共享，可動態調整數據分布。

? ? ? ? （3）可擴展性。可以線性擴展到1000多個節點，節點可動態添加或刪除。

? ? ? ? （4）高可用性。部分節點不可用時，集群仍然可用。通過增加Slave做standby數據副本，能夠實現故障自動failover，節點之間通過gossip協議交換狀態信息，用投票機制完成Slave到Master的角色提升。

? ? ? ? （5）降低運維成本，提高系統的擴展性和可用性。

? ? ? ? 缺點：

? ? ? ? （1）Client實現復雜，驅動要求實現Smart Client，緩存Slots mapping信息并及時更新，提高了開發難度，客戶端的不成熟影響業務的穩定性。目前僅有JedisCluster相對成熟，異常處理部分還不完善，比如常見的“max redirect exception”。

? ? ? ? （2）節點會因為某些原因發生阻塞（阻塞時間大于cluster-node-timeout），被判斷下線，這種failover是沒有必要的。

? ? ? ? （3）數據通過異步復制，不保證數據的強一致性。

? ? ? ? （4）多個業務使用同一套集群時，無法根據統計區分冷熱數據，資源隔離性較差，容易出現相互影響的情況。

? ? ? ? （5）Slave在集群中充當“冷備”，不能緩解讀壓力，當然可以通過SDK的合理設計來提高Slave 的資源利用率。

? ? ? ? （6）避免產生hot-key，導致主庫節點成為系統的短板。

? ? ? ? （7）避免產生big-key，導致網卡撐爆、慢查詢等。

? ? ? ? 這篇文章我們對Redis Cluster的講解進行了收尾和總結。大家有什么問題或勘誤可以在評論區留言，筆者看到都會回復的。
????????