redis深度剖析: 05 redis cluster核心原理

1、節點間的內部通訊機制

集中式的集羣元數據存儲和維護

一、基礎通訊原理

（1）redis cluster節點間採起gossip協議進行通訊

跟集中式不一樣，不是將集羣元數據（節點信息，故障，等等）集中存儲在某個節點上，而是互相之間不斷通訊，保持整個集羣全部節點的數據是完整的

維護集羣的元數據用得，集中式，一種叫作gossip

集中式：好處在於，元數據的更新和讀取，時效性很是好，一旦元數據出現了變動，當即就更新到集中式的存儲中，其餘節點讀取的時候當即就能夠感知到; 很差在於，全部的元數據的跟新壓力所有集中在一個地方，可能會致使元數據的存儲有壓力

gossip：好處在於，元數據的更新比較分散，不是集中在一個地方，更新請求會陸陸續續，打到全部節點上去更新，有必定的延時，下降了壓力; 缺點，元數據更新有延時，可能致使集羣的一些操做會有一些滯後

（2）10000端口

每一個節點都有一個專門用於節點間通訊的端口，就是本身提供服務的端口號+10000，好比7001，那麼用於節點間通訊的就是17001端口

每隔節點每隔一段時間都會往另外幾個節點發送ping消息，同時其餘幾點接收到ping以後返回pong

（3）交換的信息

故障信息，節點的增長和移除，hash slot信息，等等

二、gossip協議

gossip協議包含多種消息，包括ping，pong，meet，fail，等等

( 1 ) meet

meet: 某個節點發送meet給新加入的節點，讓新節點加入集羣中，而後新節點就會開始與其餘節點進行通訊

redis-trib.rb add-node

其實內部就是發送了一個gossip meet消息，給新加入的節點，通知那個節點去加入咱們的集羣

( 2 )ping

ping: 每一個節點都會頻繁給其餘節點發送ping，其中包含本身的狀態還有本身維護的集羣元數據，互相經過ping交換元數據

每一個節點每秒都會頻繁發送ping給其餘的集羣，ping，頻繁的互相之間交換數據，互相進行元數據的更新

( 3 )pong

pong: 返回ping和meet，包含本身的狀態和其餘信息，也能夠用於信息廣播和更新

( 4 )fail

fail: 某個節點判斷另外一個節點fail以後，就發送fail給其餘節點，通知其餘節點，指定的節點宕機了

三、ping消息深刻

ping很頻繁，並且要攜帶一些元數據，因此可能會加劇網絡負擔

每一個節點每秒會執行10次ping，每次會選擇5個最久沒有通訊的其餘節點

固然若是發現某個節點通訊延時達到了cluster_node_timeout / 2，那麼當即發送ping，避免數據交換延時過長，落後的時間太長了

好比說，兩個節點之間都10分鐘沒有交換數據了，那麼整個集羣處於嚴重的元數據不一致的狀況，就會有問題

因此cluster_node_timeout能夠調節，若是調節比較大，那麼會下降發送的頻率

每次ping，一個是帶上本身節點的信息，還有就是帶上1/10其餘節點的信息，發送出去，進行數據交換

至少包含3個其餘節點的信息，最多包含總節點-2個其餘節點的信息

2、面向集羣的jedis(java client)內部實現原理

開發，jedis，redis的java client客戶端，redis cluster，jedis cluster api

jedis cluster api與redis cluster集羣  交互的一些基本原理

一、基於重定向的客戶端

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映射表緩存的

3、高可用性與主備切換原理

redis cluster的高可用的原理，幾乎跟哨兵是相似的

一、判斷節點宕機

若是一個節點認爲另一個節點宕機，那麼就是pfail，主觀宕機

若是多個節點都認爲另一個節點宕機了，那麼就是fail，客觀宕機，跟哨兵的原理幾乎同樣(sdown，odown)

在cluster-node-timeout內，某個節點一直沒有返回pong，那麼就被認爲pfail

若是一個節點認爲某個節點pfail了，那麼會在gossip ping消息中，ping給其餘節點，若是超過半數的節點都認爲pfail了，那麼就會變成fail

二、從節點過濾

對宕機的master node，從其全部的slave node中，選擇一個切換成master node

檢查每一個slave node與master node斷開鏈接的時間，若是超過了cluster-node-timeout * cluster-slave-validity-factor，那麼就沒有資格切換成master

這個也是跟哨兵是同樣的，從節點超時過濾的步驟

三、從節點選舉

哨兵：對全部從節點進行排序，slave priority，offset，run id

每一個從節點，都根據本身對master複製數據的offset，來設置一個選舉時間，offset越大（複製數據越多）的從節點，選舉時間越靠前，優先進行選舉

全部的master node開始slave選舉投票，給要進行選舉的slave進行投票，若是大部分master node（N/2 + 1）都投票給了某個從節點，那麼選舉經過，那個從節點能夠切換成master

從節點執行主備切換，從節點切換爲主節點

四、與哨兵比較

整個流程跟哨兵相比，很是相似，因此說，redis cluster功能強大，直接集成了replication和sentinal的功能