Redis主從、哨兵、 Cluster叢集一鍋端
前言
今天跟小夥伴們一起學習Redis的主從、哨兵、Redis Cluster叢集。
Redis主從
Redis哨兵
Redis Cluster叢集
- Redis 主從
面試官經常會問到Redis的高可用。Redis高可用回答包括兩個層面，一個就是資料不能丟失，或者說盡量減少丟失;另外一個就是保證Redis服務不中斷。
對於儘量減少資料丟失，可以通過AOF和RDB保證。
對於保證服務不中斷的話，Redis就不能單點部署，這時候我們先看下Redis主從。
1.1 Redsi主從概念
Redis主從模式，就是部署多臺Redis伺服器，有主庫和從庫，它們之間通過主從複製，以保證資料副本的一致。
主從庫之間採用的是讀寫分離的方式，其中主庫負責讀操作和寫操作，從庫則負責讀操作。
如果Redis主庫掛了，切換其中的從庫成為主庫。
1.2 Redis 主從同步過程
Redis主從同步包括三個階段。
第一階段：主從庫間建立連線、協商同步。
從庫向主庫傳送psync 命令，告訴它要進行資料同步。
主庫收到 psync 命令後,響應FULLRESYNC命令（它表示第一次複製採用的是全量複製），並帶上主庫runID和主庫目前的複製進度offset。
第二階段：主庫把資料同步到從庫，從庫收到資料後，完成本地載入。
主庫執行bgsave命令，生成RDB檔案，接著將檔案發給從庫。從庫接收到RDB 檔案後，會先清空當前資料庫，然後載入 RDB 檔案。
主庫把資料同步到從庫的過程中，新來的寫操作，會記錄到replication buffer。
第三階段，主庫把新寫的命令，傳送到從庫。
主庫完成RDB傳送後，會把replication buffer中的修改操作發給從庫，從庫再重新執行這些操作。這樣主從庫就實現同步啦。
1.3 Redis主從的一些注意點
1.3.1 主從資料不一致
因為主從複製是非同步進行的，如果從庫滯後執行，則會導致主從資料不一致。
主從資料不一致一般有兩個原因：
主從庫網路延遲。
從庫收到了主從命令，但是它正在執行阻塞性的命令（如hgetall等）。
如何解決主從資料不一致問題呢？
可以換更好的硬體配置，保證網路暢通。
監控主從庫間的複製進度
1.3.2 讀取過期資料
Redis刪除資料有這幾種策略：
惰性刪除：只有當訪問一個key時，才會判斷該key是否已過期，過期則清除。
定期刪除：每隔一定的時間，會掃描一定數量的資料庫的expires字典中一定數量的key，並清除其中已過期的key。
主動刪除：當前已用記憶體超過最大限定時，觸發主動清理策略。
如果使用Redis版本低於3.2，讀從庫時，並不會判斷資料是否過期，而是會返回過期資料。而3.2 版本後，Redis做了改進，如果讀到的資料已經過期了，從庫不會刪除，卻會返回空值，避免了客戶端讀到過期資料。
因此，在主從Redis模式下，儘量使用 Redis 3.2以上的版本。
1.3.3 一主多從，全量複製時主庫壓力問題
如果是一主多從模式，從庫很多的時候，如果每個從庫都要和主庫進行全量複製的話，主庫的壓力是很大的。因為主庫fork程序生成RDB，這個fork的過程是會阻塞主執行緒處理正常請求的。同時，傳輸大的RDB檔案也會佔用主庫的網路寬頻。
可以使用主-從-從模式解決。什麼是主從從模式呢？其實就是部署主從叢集時，選擇硬體網路配置比較好的一個從庫，讓它跟部分從庫再建立主從關係。如圖：
1.3.4 主從網路斷了怎麼辦呢？
主從庫完成了全量複製後，它們之間會維護一個網路長連線，用於主庫後續收到寫命令傳輸到從庫，它可以避免頻繁建立連線的開銷。但是，如果網路斷開重連後，是否還需要進行一次全量複製呢？
如果是Redis 2.8之前，從庫和主庫重連後，確實會再進行一次全量複製，但是這樣開銷就很大。而Redis 2.8之後做了優化，重連後採用增量複製方式，即把主從庫網路斷連期間主庫收到的寫命令，同步給從庫。
主從庫重連後，就是利用repl_backlog_buffer實現增量複製。
當主從庫斷開連線後，主庫會把斷連期間收到的寫操作命令，寫入replication buffer，同時也會把這些操作命令寫入repl_backlog_buffer這個緩衝區。repl_backlog_buffer是一個環形緩衝區，主庫會記錄自己寫到的位置，從庫則會記錄自己已經讀到的位置。
- Redis哨兵
主從模式中，一旦主節點由於故障不能提供服務，需要人工將從節點晉升為主節點，同時還要通知應用方更新主節點地址。顯然，多數業務場景都不能接受這種故障處理方式。Redis從2.8開始正式提供了Redis哨兵機制來解決這個問題。
哨兵作用
哨兵模式簡介
哨兵如何判定主庫下線
哨兵模式如何工作
哨兵是如何選主的
由哪個哨兵執行主從切換呢？
哨兵下的故障轉移
2.1 哨兵作用
哨兵其實是一個執行在特殊模式下的Redis程序。它有三個作用，分別是：監控、自動選主切換（簡稱選主）、通知。
哨兵程序在執行期間，監視所有的Redis主節點和從節點。它通過週期性給主從庫傳送PING命令，檢測主從庫是否掛了。如果從庫沒有在規定時間內響應哨兵的PING命令，哨兵就會把它標記為下線狀態；如果主庫沒有在規定時間內響應哨兵的PING命令，哨兵則會判定主庫下線，然後開始切換到選主任務。
所謂選主，其實就是從多個從庫中，按照一定規則，選出一個當做主庫。至於通知呢，就是選出主庫後，哨兵把新主庫的連線資訊發給其他從庫，讓它們和新主庫建立主從關係。同時，哨兵也會把新主庫的連線資訊通知給客戶端，讓它們把請求操作發到新主庫上。
2.2 哨兵模式
因為Redis哨兵也是一個Redis程序，如果它自己掛了呢，那是不是就起不了監控的作用啦。我們一起來看下Redis哨兵模式
哨兵模式，就是由一個或多個哨兵例項組成的哨兵系統，它可以監視所有的Redis主節點和從節點，並在被監視的主節點進入下線狀態時，自動將下線主伺服器屬下的某個從節點升級為新的主節點。，一個哨兵程序對Redis節點進行監控，就可能會出現問題（單點問題）。因此，一般使用多個哨兵來進行監控Redis節點，並且各個哨兵之間還會進行監控。
其實哨兵之間是通過釋出訂閱機制組成叢集的，同時，哨兵又通過INFO命令，獲得了從庫連線資訊，也能和從庫建立連線，從而進行監控。
2.3 哨兵如何判定主庫下線
哨兵是如何判斷主庫是否下線的呢？我們先來了解兩個基礎概念哈：主觀下線和客觀下線。
哨兵程序向主庫、從庫傳送PING命令，如果主庫或者從庫沒有在規定的時間內響應PING命令，哨兵就把它標記為主觀下線。
如果是主庫被標記為主觀下線，則正在監視這個主庫的所有哨兵要以每秒一次的頻率，以確認主庫是否真的進入了主觀下線。當有多數的哨兵（一般少數服從多數，由 Redis 管理員自行設定的一個值）在指定的時間範圍內確認主庫的確進入了主觀下線狀態，則主庫會被標記為客觀下線。這樣做的目的就是避免對主庫的誤判，以減少沒有必要的主從切換，減少不必要的開銷。
假設我們有N個哨兵例項，如果有N/2+1個例項判斷主庫主觀下線，此時就可以把節點標記為客觀下線，就可以做主從切換了。
2.4 哨兵的工作模式
每個哨兵以每秒鐘一次的頻率向它所知的主庫、從庫以及其他哨兵例項傳送一個PING命令。
如果一個例項節點距離最後一次有效回覆PING命令的時間超過down-after-milliseconds選項所指定的值， 則這個例項會被哨兵標記為主觀下線。
如果主庫被標記為主觀下線，則正在監視這個主庫的所有哨兵要以每秒一次的頻率確認主庫的確進入了主觀下線狀態。
當有足夠數量的哨兵（大於等於配置檔案指定的值）在指定的時間範圍內確認主庫的確進入了主觀下線狀態， 則主庫會被標記為客觀下線。
當主庫被哨兵標記為客觀下線時，就會進入選主模式。
若沒有足夠數量的哨兵同意主庫已經進入主觀下線， 主庫的主觀下線狀態就會被移除；若主庫重新向哨兵的PING命令返回有效回覆，主庫的主觀下線狀態就會被移除。
2.5 哨兵是如何選主的？
如果明確主庫已經客觀下線了，哨兵就開始了選主模式。
哨兵選主包括兩大過程，分別是：過濾和打分。其實就是在多個從庫中，先按照一定的篩選條件，把不符合條件的從庫過濾掉。然後再按照一定的規則，給剩下的從庫逐個打分，將得分最高的從庫選為新主庫
選主時，會判斷從庫的狀態，如果已經下線，就直接過濾。
如果從庫網路不好，老是超時，也會被過濾掉。看這個引數down-after-milliseconds，它表示我們認定主從庫斷連的最大連線超時時間。
過濾掉了不適合做主庫的從庫後，就可以給剩下的從庫打分，按這三個規則打分：從庫優先順序、從庫複製進度以及從庫ID號。
從庫優先順序最高的話，打分就越高，優先順序可以通過slave-priority配置。如果優先順序一樣，就選與舊的主庫複製進度最快的從庫。如果優先順序和從庫進度都一樣，從庫ID 號小的打分高。
2.6 由哪個哨兵執行主從切換呢？
一個哨兵標記主庫為主觀下線後，它會徵求其他哨兵的意見，確認主庫是否的確進入了主觀下線狀態。它向其他例項哨兵傳送is-master-down-by-addr命令。其他哨兵會根據自己和主庫的連線情況，迴應Y或N（Y 表示贊成，N表示反對票）。如果這個哨兵獲取得足夠多的贊成票數（quorum配置），主庫會被標記為客觀下線。
標記主庫客觀下線的這個哨兵，緊接著向其他哨兵傳送命令，再發起投票，希望它可以來執行主從切換。這個投票過程稱為Leader 選舉。因為最終執行主從切換的哨兵稱為Leader，投票過程就是確定Leader。一個哨兵想成為Leader需要滿足兩個條件：
需要拿到num(sentinels)/2+1的贊成票。
並且拿到的票數需要大於等於哨兵配置檔案中的quorum值。
舉個例子，假設有3個哨兵。配置的quorum值為2。即一個一個哨兵想成為Leader至少需要拿到2張票。為了更好理解，大家可以看下
在t1時刻，哨兵A1判斷主庫為客觀下線，它想成為主從切換的Leader，於是先給自己投一張贊成票，然後分別向哨兵A2 和A3發起投票命令，表示想成為 Leader。
在 t2 時刻，A3 判斷主庫為客觀下線，它也想成為 Leader，所以也先給自己投一張贊成票，再分別向 A1 和 A2 發起投票命令，表示也要成為 Leader。
在 t3 時刻，哨兵A1 收到了A3 的Leader投票請求。因為A1已經把票Y投給自己了，所以它不能再給其他哨兵投贊成票了，所以A1投票N給A3。
在 t4時刻，哨兵A2收到A3 的Leader投票請求，因為哨兵A2之前沒有投過票，它會給第一個向它傳送投票請求的哨兵回覆贊成票Y。
在 t5時刻，哨兵A2收到A1 的Leader投票請求，因為哨兵A2之前已經投過贊成票給A3了，所以它只能給A1投反對票N。
最後t6時刻，哨兵A1只收到自己的一票Y贊成票，而哨兵A3得到兩張贊成票（A2和A3投的），因此哨兵A3成為了Leader。
假設網路故障等原因，哨兵A3也沒有收到兩張票，那麼這輪投票就不會產生Leader。哨兵叢集會等待一段時間（一般是哨兵故障轉移超時時間的2倍），再進行重新選舉。
2.7 故障轉移
假設哨兵模式架構如下，有三個哨兵，一個主庫M，兩個從庫S1和S2。
當哨兵檢測到Redis主庫M1出現故障，那麼哨兵需要對叢集進行故障轉移。假設選出了哨兵3作為Leader。故障轉移流程如下：
從庫S1解除從節點身份，升級為新主庫
從庫S2成為新主庫的從庫
原主節點恢復也變成新主庫的從節點
通知客戶端應用程式新主節點的地址。
故障轉移後：
3.Redis Cluster叢集
哨兵模式基於主從模式，實現讀寫分離，它還可以自動切換，系統可用性更高。但是它每個節點儲存的資料是一樣的，浪費記憶體，並且不好線上擴容。因此，Reids Cluster叢集（切片叢集的實現方案）應運而生，它在Redis3.0加入的，實現了Redis的分散式儲存。對資料進行分片，也就是說每臺Redis節點上儲存不同的內容，來解決線上擴容的問題。並且，它可以儲存大量資料，即分散資料到各個Redis例項，還提供複製和故障轉移的功能。
比如你一個Redis例項儲存15G甚至更大的資料，響應就會很慢，這是因為Redis RDB 持久化機制導致的，Redis會fork子程序完成 RDB 持久化操作，fork執行的耗時與 Redis 資料量成正相關。
這時候你很容易想到，把15G資料分散來儲存就好了嘛。這就是Redis切片叢集的初衷。切片叢集是啥呢？來看個例子，如果你要用Redis儲存15G的資料，可以用單例項Redis，或者3臺Redis例項組成切片叢集，對比如下：
切片叢集和Redis Cluster 的區別：Redis Cluster是從Redis3.0版本開始，官方提供的一種實現切片叢集的方案。
既然資料是分片分佈到不同Redis例項的，那客戶端到底是怎麼確定想要訪問的資料在哪個例項上呢？我們一起來看下Reids Cluster是怎麼做的哈。
3.1 雜湊槽（Hash Slot）
Redis Cluster方案採用雜湊槽（Hash Slot），來處理資料和例項之間的對映關係。
一個切片叢集被分為16384個slot（槽），每個進入Redis的鍵值對，根據key進行雜湊，分配到這16384插槽中的一個。使用的雜湊對映也比較簡單，用CRC16演算法計算出一個16bit的值，再對16384取模。資料庫中的每個鍵都屬於這16384個槽的其中一個，叢集中的每個節點都可以處理這16384個槽。
叢集中的每個節點負責一部分的雜湊槽，假設當前叢集有A、B、C3個節點，每個節點上負責的雜湊槽數 =16384/3，那麼可能存在的一種分配：
節點A負責0~5460號雜湊槽
節點B負責5461~10922號雜湊槽
節點C負責10923~16383號雜湊槽
客戶端給一個Redis例項傳送資料讀寫操作時，如果這個例項上並沒有相應的資料，會怎麼樣呢？MOVED重定向和ASK重定向瞭解一下哈
3.2 MOVED重定向和ASK重定向
在Redis cluster模式下，節點對請求的處理過程如下：
通過雜湊槽對映，檢查當前Redis key是否存在當前節點
若雜湊槽不是由自身節點負責，就返回MOVED重定向
若雜湊槽確實由自身負責，且key在slot中，則返回該key對應結果
若Redis key不存在此雜湊槽中，檢查該雜湊槽是否正在遷出（MIGRATING）？
若Redis key正在遷出，返回ASK錯誤重定向客戶端到遷移的目的伺服器上
若雜湊槽未遷出，檢查雜湊槽是否匯入中？
若雜湊槽匯入中且有ASKING標記，則直接操作，否則返回MOVED重定向
3.2.1 Moved 重定向
客戶端給一個Redis例項傳送資料讀寫操作時，如果計算出來的槽不是在該節點上，這時候它會返回MOVED重定向錯誤，MOVED重定向錯誤中，會將雜湊槽所在的新例項的IP和port埠帶回去。這就是Redis Cluster的MOVED重定向機制。流程圖如下：
3.2.2 ASK 重定向
Ask重定向一般發生於叢集伸縮的時候。叢集伸縮會導致槽遷移，當我們去源節點訪問時，此時資料已經可能已經遷移到了目標節點，使用Ask重定向可以解決此種情況。
3.3 Cluster叢集節點的通訊協議：Gossip
一個Redis叢集由多個節點組成，各個節點之間是怎麼通訊的呢？通過Gossip協議！Gossip是一種謠言傳播協議，每個節點週期性地從節點列表中選擇 k 個節點，將本節點儲存的資訊傳播出去，直到所有節點資訊一致，即演算法收斂了。
Gossip協議基本思想：一個節點想要分享一些資訊給網路中的其他的一些節點。於是，它週期性的隨機選擇一些節點，並把資訊傳遞給這些節點。這些收到資訊的節點接下來會做同樣的事情，即把這些資訊傳遞給其他一些隨機選擇的節點。一般而言，資訊會週期性的傳遞給N個目標節點，而不只是一個。這個N被稱為fanout
Redis Cluster叢集通過Gossip協議進行通訊，節點之前不斷交換資訊，交換的資訊內容包括節點出現故障、新節點加入、主從節點變更資訊、slot資訊等等。gossip協議包含多種訊息型別，包括ping，pong，meet，fail，等等
meet訊息：通知新節點加入。訊息傳送者通知接收者加入到當前叢集，meet訊息通訊正常完成後，接收節點會加入到叢集中並進行週期性的ping、pong訊息交換。
ping訊息：節點每秒會向叢集中其他節點發送 ping 訊息，訊息中帶有自己已知的兩個節點的地址、槽、狀態資訊、最後一次通訊時間等
pong訊息：當接收到ping、meet訊息時，作為響應訊息回覆給傳送方確認訊息正常通訊。訊息中同樣帶有自己已知的兩個節點資訊。
fail訊息：當節點判定叢集內另一個節點下線時，會向叢集內廣播一個fail訊息，其他節點接收到fail訊息之後把對應節點更新為下線狀態。
特別的，每個節點是通過叢集匯流排(cluster bus) 與其他的節點進行通訊的。通訊時，使用特殊的埠號，即對外服務埠號加10000。例如如果某個node的埠號是6379，那麼它與其它nodes通訊的埠號是 16379。nodes 之間的通訊採用特殊的二進位制協議。
3.4 故障轉移
Redis叢集實現了高可用，當叢集內節點出現故障時，通過故障轉移，以保證叢集正常對外提供服務。
redis叢集通過ping/pong訊息，實現故障發現。這個環境包括主觀下線和客觀下線。
主觀下線： 某個節點認為另一個節點不可用，即下線狀態，這個狀態並不是最終的故障判定，只能代表一個節點的意見，可能存在誤判情況。
主觀下線
客觀下線： 指標記一個節點真正的下線，叢集內多個節點都認為該節點不可用，從而達成共識的結果。如果是持有槽的主節點故障，需要為該節點進行故障轉移。
假如節點A標記節點B為主觀下線，一段時間後，節點A通過訊息把節點B的狀態發到其它節點，當節點C接受到訊息並解析出訊息體時，如果發現節點B的pfail狀態時，會觸發客觀下線流程；
當下線為主節點時，此時Redis Cluster叢集為統計持有槽的主節點投票，看投票數是否達到一半，當下線報告統計數大於一半時，被標記為客觀下線狀態。
流程如下：
客觀下線
故障恢復：故障發現後，如果下線節點的是主節點，則需要在它的從節點中選一個替換它，以保證叢集的高可用。流程如下：
資格檢查：檢查從節點是否具備替換故障主節點的條件。
準備選舉時間：資格檢查通過後，更新觸發故障選舉時間。
發起選舉：到了故障選舉時間，進行選舉。
選舉投票：只有持有槽的主節點才有票，從節點收集到足夠的選票（大於一半），觸發替換主節點操作
3.5 加餐：為什麼Redis Cluster的Hash Slot 是16384？
對於客戶端請求過來的鍵值key，雜湊槽=CRC16(key) % 16384，CRC16演算法產生的雜湊值是16bit的，按道理該演算法是可以產生216=65536個值，為什麼不用65536，用的是16384（214）呢？
大家可以看下作者的原始回答：
Redis 每個例項節點上都儲存對應有哪些slots，它是一個 unsigned char slots[REDIS_CLUSTER_SLOTS/8] 型別
在redis節點發送心跳包時需要把所有的槽放到這個心跳包裡，如果slots數量是 65536 ，佔空間= 65536 / 8(一個位元組8bit) / 1024(1024個位元組1kB) =8kB ，如果使用slots數量是 16384 ，所佔空間 = 16384 / 8(每個位元組8bit) / 1024(1024個位元組1kB) = 2kB ，可見16384個slots比 65536省 6kB記憶體左右，假如一個叢集有100個節點,那每個例項裡就省了600kB啦
一般情況下Redis cluster叢集主節點數量基本不可能超過1000個，超過1000會導致網路擁堵。對於節點數在1000以內的Redis cluster叢集，16384個槽位其實夠用了。
既然為了節省記憶體網路開銷，為什麼 slots不選擇用8192（即16384/2） 呢?
8192 / 8(每個位元組8bit) / 1024(1024個位元組1kB) = 1kB ,只需要1KB！可以先看下Redis 把 Key 換算成所屬 slots 的方法
unsigned int keyHashSlot(char key, int keylen) {
int s, e; / start-end indexes of { and } */
for (s = 0; s < keylen; s++)
if (key[s] == '{') break;
/* No '{' ? Hash the whole key. This is the base case. */
if (s == keylen) return crc16(key,keylen) & 0x3FFF;
/* '{' found? Check if we have the corresponding '}'. */
for (e = s+1; e < keylen; e++)
if (key[e] == '}') break;
/* No '}' or nothing betweeen {} ? Hash the whole key. */
if (e == keylen || e == s+1) return crc16(key,keylen) & 0x3FFF;
/* If we are here there is both a { and a } on its right. Hash
* what is in the middle between { and }. */
return crc16(key+s+1,e-s-1) & 0x3FFF;
}
Redis 將key換算成slots 的方法：其實就是是將crc16(key) 之後再和slots的數量進行與計算
這裡為什麼用0x3FFF(16383) 來計算,而不是16384呢？因為在不產生溢位的情況下 x % (2^n)等價於x & (2^n - 1)即 x % 16384 == x & 16383
那到底為什麼不用8192呢？
crc16 出來結果,理論上出現重複的概率為 1⁄65536,但實際結果重複概率可能比這個大不少,就像crc32 結果 理論上 1/40億 分之一,但實際有人測下來10萬碰撞的概率就比較大了。假如 slots 設定成 8192, 200個例項的節點情況下,理論值是 每40個不同key請求,命中就會失效一次,假如節點數增加到400,那就是20個請求。並且1kb 並不會比 2k 省太多,價效比不是特別高,所以可能 選16384會更為通用一點