Redis專題地址：https://www.cnblogs.com/hello-shf/category/1615909.html
SpringBoot讀源碼系列：https://www.cnblogs.com/hello-shf/category/1456313.html
Elasticsearch系列：https://www.cnblogs.com/hello-shf/category/1550315.html
數據結構系列：https://www.cnblogs.com/hello-shf/category/1519192.html
一、redis cluster
在redis3.0之前，如果想搭建一個集群架構還是挺復雜的，就算是基於一些第三方的中間件搭建的集群總感覺有那么點差強人意。或者基於sentinel哨兵搭建的主從架構在高可用上表現又不是很好，尤其是當數據量越來越大，單純主從結構無法滿足對性能的需求時，矛盾便產生了。
隨着redis cluster的推出，這種海量數據+高並發+高可用的場景真正從根本上得到了有效的支持。
二、集群內部通信
在redis cluster集群內部通過gossip協議進行通信，集群元數據分散的存在於各個節點，通過gossip進行元數據的交換。
不同於zookeeper分布式協調中間件，采用集中式的集群元數據存儲。redis cluster采用分布式的元數據管理，優缺點還是比較明顯的。
在redis中集中式的元數據管理類似sentinel主從架構模式。集中式有點在於元數據更新實效性更高，但容錯性不如分布式管理。gossip協議優點在於大大增強集群容錯性。
redis cluster集群中單節點一般配置兩個端口，一個端口如6379對外提供api，另一個一般是加1w，比如16379進行節點間的元數據交換即用於gossip協議通訊。
gossip協議包含多種消息，如ping pong，meet，fail等。
1 meet：集群中節點通過向新加入節點發送meet消息，將新節點加入集群。 2 ping：節點間通過ping命令交換元數據。 3 pong：響應ping。 4 fail：某個節點主觀認為某個節點宕機，會向其他節點發送fail消息，進行客觀宕機判定。
三、集群高可用和主備切換
主觀宕機和客觀宕機：
某個節點會周期性的向其他節點發送ping消息，當在一定時間內未收到pong消息會主觀認為該節點宕機，即主觀宕機。然后該節點向其他節點發送fail消息，其他超過半數節點也確認該節點宕機，即客觀宕機。十分類似sentinel的sdown和odown。
客觀宕機確認后進入主備切換階段及從節點選舉。
節點選舉：
檢查每個 slave node 與 master node 斷開連接的時間，如果超過了 cluster-node-timeout * cluster-slave-validity-factor，那么就沒有資格切換成 master。
每個從節點，都根據自己對 master 復制數據的 offset，來設置一個選舉時間，offset 越大（復制數據越多）的從節點，選舉時間越靠前，優先進行選舉。
所有的 master node 開始 slave 選舉投票，給要進行選舉的 slave 進行投票，如果大部分 master node（N/2 + 1）都投票給了某個從節點，那么選舉通過，那個從節點可以切換成 master。
從節點執行主備切換，從節點切換為主節點。
四、分片和尋址算法
hash slot即hash槽。redis cluster采用的正式這種hash槽算法實現的尋址。
在redis cluster中固定的存在16384個hash slot。
hash slot = CRC16（key）%16384；
#CRC16算法可以簡單的理解為一種hash算法。詳見度娘。
這樣我們就能找到key對應的hash slot。其實按照我的理解，hash slot就是在尋址和節點間加了一層映射關系。當節點動態變化，只需要改變hash slot ==> 節點的映射，然后只需要遷移指定slot到新添加的節點即可。既減少了hash尋址帶來的數據全量遷移問題，相對一致性hash也使得負載均衡效果更加明顯。
如上圖，如果我們有三個節點。redis cluster初始化時會自動均分給每個節點16384個slot。
當增加一個節點4，只需要將原來node1~node3節點部分slot上的數據遷移到節點4即可。在redis cluster中數據遷移並不會阻塞主進程。對性能影響是十分有限的。總結一句話就是hash slot算法有效的減少了當節點發生變化導致的數據漂移帶來的性能開銷。
更多分布式尋址算法可參考：https://www.cnblogs.com/hello-shf/p/12079986.html
五、對比sentinel
相比Sentinel主從架構，redis cluster中各個節點是對等的，類似elasticsearch的節點對等原理。
節點對等是我從elasticsearch copy過來的概念，但是用在這里還是很合理的。
Sentinel主從架構我們都知道只能搭建出來一個主從的架構（當然從還可以作為其它從的主），比較適合讀寫分離，原則上沒有實現海量數據的分片。而Redis正是彌補了Sentinel無法實現海量數據的高可用，Redis cluster通過分片實現海量數據+高可用的高並發架構。
假如有100個數據，在sentinel中主節點完全存儲100條數據，而在Redis cluster中通過hash slot將數據分片，平均分布在多個節點上，實現了海量數據的分片。原則上來說，Redis cluster才是真正的分布式架構。
有關Sentinel可參考：https://www.cnblogs.com/hello-shf/p/12072330.html
如有錯誤的地方還請留言指正。
原創不易，轉載請注明原文地址：https://www.cnblogs.com/hello-shf/p/12080123.html
參考文獻：
https://github.com/hello-shf/advanced-java