redis集群的概述:
在以前，如果前幾年的時候，一般來說，redis如果要搞幾個節點，每個節點存儲一部分的數據，得借助一些中間件來實現，比如說有codis，或者twemproxy，都有。有一些redis中間件，你讀寫redis中間件，redis中間件負責將你的數據分布式存儲在多台機器上的redis實例中。
這兩年，redis不斷在發展，redis也不斷的有新的版本，redis cluster，redis集群模式，你可以做到在多台機器上，部署多個redis實例，每個實例存儲一部分的數據，同時每個redis實例可以掛redis從實例，自動確保說，如果redis主實例掛了，會自動切換到redis從實例頂上來。
現在redis的新版本，大家都是用redis cluster的，也就是redis原生支持的redis集群模式，
單機redis在海量數據面前的瓶頸
怎么才能夠突破單機瓶頸，讓redis支撐海量數據？
redis的集群架構
redis cluster
支撐n個redis master node,每個master node 都可以掛載多個slave node
讀寫分離的架構,對於每個master來說,寫就寫到master,然后讀就從mater對應的slave去讀
高可用,因為每個master都有slave節點,那么如果master掛掉了,redis cluster這套機制,就會將某個slave切換成master
redis cluster(多master +讀寫分離+高可用)
我們只要基於redis cluster 去搭建redis集群即可,不需要手工搭建replication復制+主從架構+讀寫分離+哨兵集群+高可用.
redis cluster vs replication +sentinal
如果你的數據量很少,主要是承載高並發高性能的場景,比如你的緩存一般就幾個G,單機就足夠了,
replication,一個master ,多個slave,要幾個slave跟你的要求的讀吞吐量有關系,然后自己搭建一個sentinal集群,去保證redis主從架構的高可用行,就可以.
redis cluster ,主要針對的是海量數據+高並發+高可用的場景,海量數據,如果你的數據量很大,那么建議就用redis cluster
講解分布式數據存儲的核心算法，數據分布的算法
hash算法 -> 一致性hash算法（memcached） -> redis cluster，hash slot算法
用不同的算法，就決定了在多個master節點的時候，數據如何分布到這些節點上去，解決這個問題
redis cluster介紹:
redis cluster
（1）自動將數據進行分片，每個master上放一部分數據
（2）提供內置的高可用支持，部分master不可用時，還是可以繼續工作的
在redis cluster架構下，每個redis要放開兩個端口號，比如一個是6379，另外一個就是加10000的端口號，比如16379
16379端口號是用來進行節點間通信的，也就是cluster bus的東西，集群總線。cluster bus的通信，用來進行故障檢測，配置更新，故障轉移授權
cluster bus用了另外一種二進制的協議，主要用於節點間進行高效的數據交換，占用更少的網絡帶寬和處理時間
2、最老土的hash算法和弊端（大量緩存重建）
3、一致性hash算法（自動緩存遷移）+虛擬節點（自動負載均衡）
虛擬節點:
4、redis cluster的hash slot算法
redis cluster有固定的16384個hash slot，對每個key計算CRC16值，然后對16384取模，可以獲取key對應的hash slot
redis cluster中每個master都會持有部分slot，比如有3個master，那么可能每個master持有5000多個hash slot
hash slot讓node的增加和移除很簡單，增加一個master，就將其他master的hash slot移動部分過去，減少一個master，就將它的hash slot移動到其他master上去
移動hash slot的成本是非常低的
客戶端的api，可以對指定的數據，讓他們走同一個hash slot，通過hash tag來實現
節點間的內部通信機制
1、基礎通信原理
（1）redis cluster節點間采取gossip協議進行通信
跟集中式不同，不是將集群元數據（節點信息，故障，等等）集中存儲在某個節點上，而是互相之間不斷通信，保持整個集群所有節點的數據是完整的
維護集群的元數據用得，集中式，一種叫做gossip
集中式：好處在於，元數據的更新和讀取，時效性非常好，一旦元數據出現了變更，立即就更新到集中式的存儲中，其他節點讀取的時候立即就可以感知到; 不好在於，所有的元數據的跟新壓力全部集中在一個地方，可能會導致元數據的存儲有壓力
gossip：好處在於，元數據的更新比較分散，不是集中在一個地方，更新請求會陸陸續續，打到所有節點上去更新，有一定的延時，降低了壓力; 缺點，元數據更新有延時，可能導致集群的一些操作會有一些滯后
我們剛才做reshard，去做另外一個操作，會發現說，configuration error，達成一致
（2）10000端口
每個節點都有一個專門用於節點間通信的端口，就是自己提供服務的端口號+10000，比如7001，那么用於節點間通信的就是17001端口
每隔節點每隔一段時間都會往另外幾個節點發送ping消息，同時其他幾點接收到ping之后返回pong
（3）交換的信息
故障信息，節點的增加和移除，hash slot信息，等等
gossip協議
gossip協議包含多種消息，包括ping，pong，meet，fail，等等
meet: 某個節點發送meet給新加入的節點，讓新節點加入集群中，然后新節點就會開始與其他節點進行通信
redis-trib.rb add-node
其實內部就是發送了一個gossip meet消息，給新加入的節點，通知那個節點去加入我們的集群
ping: 每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過ping交換元數據
每個節點每秒都會頻繁發送ping給其他的集群，ping，頻繁的互相之間交換數據，互相進行元數據的更新
pong: 返回ping和meet，包含自己的狀態和其他信息，也可以用於信息廣播和更新
fail: 某個節點判斷另一個節點fail之后，就發送fail給其他節點，通知其他節點，指定的節點宕機了
3、ping消息深入
ping很頻繁，而且要攜帶一些元數據，所以可能會加重網絡負擔
每個節點每秒會執行10次ping，每次會選擇5個最久沒有通信的其他節點
當然如果發現某個節點通信延時達到了cluster_node_timeout / 2，那么立即發送ping，避免數據交換延時過長，落后的時間太長了
比如說，兩個節點之間都10分鍾沒有交換數據了，那么整個集群處於嚴重的元數據不一致的情況，就會有問題
所以cluster_node_timeout可以調節，如果調節比較大，那么會降低發送的頻率
每次ping，一個是帶上自己節點的信息，還有就是帶上1/10其他節點的信息，發送出去，進行數據交換
至少包含3個其他節點的信息，最多包含總節點-2個其他節點的信息
-------------------------------------------------------------------------------------------------------
面向集群的jedis內部實現原理
開發，jedis，redis的java client客戶端，redis cluster，jedis cluster api
jedis cluster api與redis cluster集群交互的一些基本原理
1、基於重定向的客戶端
redis-cli -c，自動重定向
（1）請求重定向
客戶端可能會挑選任意一個redis實例去發送命令，每個redis實例接收到命令，都會計算key對應的hash slot
如果在本地就在本地處理，否則返回moved給客戶端，讓客戶端進行重定向
cluster keyslot mykey，可以查看一個key對應的hash slot是什么
用redis-cli的時候，可以加入-c參數，支持自動的請求重定向，redis-cli接收到moved之后，會自動重定向到對應的節點執行命令
（2）計算hash slot
計算hash slot的算法，就是根據key計算CRC16值，然后對16384取模，拿到對應的hash slot
用hash tag可以手動指定key對應的slot，同一個hash tag下的key，都會在一個hash slot中，比如set mykey1:{100}和set mykey2:{100}
（3）hash slot查找
節點間通過gossip協議進行數據交換，就知道每個hash slot在哪個節點上
smart jedis
（1）什么是smart jedis
基於重定向的客戶端，很消耗網絡IO，因為大部分情況下，可能都會出現一次請求重定向，才能找到正確的節點
所以大部分的客戶端，比如java redis客戶端，就是jedis，都是smart的
本地維護一份hashslot -> node的映射表，緩存，大部分情況下，直接走本地緩存就可以找到hashslot -> node，不需要通過節點進行moved重定向
（2）JedisCluster的工作原理
在JedisCluster初始化的時候，就會隨機選擇一個node，初始化hashslot -> node映射表，同時為每個節點創建一個JedisPool連接池
每次基於JedisCluster執行操作，首先JedisCluster都會在本地計算key的hashslot，然后在本地映射表找到對應的節點
如果那個node正好還是持有那個hashslot，那么就ok; 如果說進行了reshard這樣的操作，可能hashslot已經不在那個node上了，就會返回moved
如果JedisCluter API發現對應的節點返回moved，那么利用該節點的元數據，更新本地的hashslot -> node映射表緩存
重復上面幾個步驟，直到找到對應的節點，如果重試超過5次，那么就報錯，JedisClusterMaxRedirectionException
jedis老版本，可能會出現在集群某個節點故障還沒完成自動切換恢復時，頻繁更新hash slot，頻繁ping節點檢查活躍，導致大量網絡IO開銷
jedis最新版本，對於這些過度的hash slot更新和ping，都進行了優化，避免了類似問題
（3）hashslot遷移和ask重定向
如果hash slot正在遷移，那么會返回ask重定向給jedis
jedis接收到ask重定向之后，會重新定位到目標節點去執行，但是因為ask發生在hash slot遷移過程中，所以JedisCluster API收到ask是不會更新hashslot本地緩存
已經可以確定說，hashslot已經遷移完了，moved是會更新本地hashslot->node映射表緩存的
-------------------------------------------------------------------------------------------------------
高可用性與主備切換原理
redis cluster的高可用的原理，幾乎跟哨兵是類似的
1、判斷節點宕機
如果一個節點認為另外一個節點宕機，那么就是pfail，主觀宕機
如果多個節點都認為另外一個節點宕機了，那么就是fail，客觀宕機，跟哨兵的原理幾乎一樣，sdown，odown
在cluster-node-timeout內，某個節點一直沒有返回pong，那么就被認為pfail
如果一個節點認為某個節點pfail了，那么會在gossip ping消息中，ping給其他節點，如果超過半數的節點都認為pfail了，那么就會變成fail
2、從節點過濾
對宕機的master node，從其所有的slave node中，選擇一個切換成master node
檢查每個slave node與master node斷開連接的時間，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那么就沒有資格切換成master
這個也是跟哨兵是一樣的，從節點超時過濾的步驟
3、從節點選舉
哨兵：對所有從節點進行排序，slave priority，offset，run id
每個從節點，都根據自己對master復制數據的offset，來設置一個選舉時間，offset越大（復制數據越多）的從節點，選舉時間越靠前，優先進行選舉
所有的master node開始slave選舉投票，給要進行選舉的slave進行投票，如果大部分master node（N/2 + 1）都投票給了某個從節點，那么選舉通過，那個從節點可以切換成master
從節點執行主備切換，從節點切換為主節點
4、與哨兵比較
整個流程跟哨兵相比，非常類似，所以說，redis cluster功能強大，直接集成了replication和sentinal的功能