redis cluster集羣模式原理

從石杉碼農課程整理而來

你能聊聊redis cluster集羣模式的原理嗎？

一、面試題redis集羣模式的工做原理能說一下麼？在集羣模式下，redis的key是如何尋址的？分佈式尋址都有哪些算法？瞭解一致性hash算法嗎？

二、面試官心理分析

在之前，若是前幾年的時候，通常來講，redis若是要搞幾個節點，每一個節點存儲一部分的數據，得藉助一些中間件來實現，好比說有codis，或者twemproxy，都有。有一些redis中間件，你讀寫redis中間件，redis中間件負責將你的數據分佈式存儲在多臺機器上的redis實例中。這兩年，redis不斷在發展，redis也不斷的有新的版本，redis cluster，redis集羣模式，你能夠作到在多臺機器上，部署多個redis實例，每一個實例存儲一部分的數據，同時每一個redis實例能夠掛redis從實例，自動確保說，若是redis主實例掛了，會自動切換到redis從實例頂上來。如今redis的新版本，你們都是用redis cluster的，也就是redis原生支持的redis集羣模式，那麼面試官確定會就redis cluster對你來個幾連炮。要是你沒用過redis cluster，正常，之前不少人用codis之類的客戶端來支持集羣，可是起碼你得研究一下redis cluster吧。

redis如何在保持讀寫分離+高可用的架構下，還能橫向擴容支持1T+的海量數據？

一、單機redis在海量數據面前的瓶頸

二、怎麼纔可以突破單機瓶頸，讓redis支撐海量數據？

三、redis的集羣架構

redis cluster

支撐N個redis master node，每一個master node均可以掛載多個slave node

讀寫分離的架構，對於每一個master來講，寫就寫到master，而後讀就從mater對應的slave去讀

高可用，由於每一個master都有salve節點，那麼若是mater掛掉，redis cluster這套機制，就會自動將某個slave切換成master

redis cluster（多master + 讀寫分離 + 高可用）

咱們只要基於redis cluster去搭建redis集羣便可，不須要手工去搭建replication複製+主從架構+讀寫分離+哨兵集羣+高可用

四、redis cluster vs. replication + sentinal

若是你的數據量不多，主要是承載高併發高性能的場景，好比你的緩存通常就幾個G，單機足夠了

replication，一個mater，多個slave，要幾個slave跟你的要求的讀吞吐量有關係，而後本身搭建一個sentinal集羣，去保證redis主從架構的高可用性，就能夠了

redis cluster，主要是針對海量數據+高併發+高可用的場景，海量數據，若是你的數據量很大，那麼建議就用redis cluster

一致性Hash及redis cluster的hash slot

講解分佈式數據存儲的核心算法，數據分佈的算法

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用了另一種二進制的協議，主要用於節點間進行高效的數據交換，佔用更少的網絡帶寬和處理時間

二、最老土的hash算法和弊端（大量緩存重建）

好比cluster中有三臺master機器，某一個master宕機了，就要從新對剩下2臺master取模，再分佈到其餘的節點上去。

對於高併發的系統來講，是不可接受的，這會致使請求直接打到數據庫上，從而將數據庫壓垮。

一臺機器宕機後，所有請求過來會發現，要基於最新的master個數取模而後獲取數據，這將致使幾乎大部分的請求，沒法拿到有效的緩存，大量的流量就會涌入數據庫中。

三、一致性hash算法（自動緩存遷移）+虛擬節點（自動負載均衡）

一致性hash

一致性hash算法，能夠保證任何一個master宕機，只有以前在那個master上的數據會受到影響，由於照着順時針走，所有在以前的master上的數據找不到了，會順時針去下一個master找，也會找不到。這樣只有1/3的流量會涌入到數據庫中從新查詢。

虛擬節點

緩存熱點的問題，可能集中在某個hash區間內的值特別多，那麼會致使大量的數據庫都涌入同一個master內，形成master的熱點問題，性能出現瓶頸。

虛擬結點

四、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來實現

redis cluster核心原理分析

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給其餘節點，通知其餘節點，指定的節點宕機了

三、ping消息深刻

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

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

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

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

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

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

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

---

2、面向集羣的jedis內部實現原理

開發，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的功能

沒有辦法去給你們深刻講解redis底層的設計的細節，核心原理和設計的細節，那個除非單獨開一門課，redis底層原理深度剖析，redis源碼

對於我們這個架構課來講，主要關注的是架構，不是底層的細節，對於架構來講，核心的原理的基本思路，是要梳理清晰的