摘要：Redis在主從模式下會有許多問題需要考慮，這裡寫了一些關于redis在多伺服器下的一些問題分析和總結。
Redis單節點存在單點故障問題，為了解決單點問題，一般都需要對redis配置從節點，然後使用哨兵來監聽主節點的存活狀态，如果主節點挂掉，從節點能繼續提供緩存功能。主從配置結合哨兵模式能解決單點故障問題，提高redis可用性。從節點僅提供讀操作，主節點提供寫操作。對于讀多寫少的狀況，可給主節點配置多個從節點，進而提高響應效率。
主從複制過程：
- 從節點執行slaveof[masterIP][masterPort]，儲存主節點資訊
- 從節點中的定時任務發現主節點資訊，建立和主節點的socket連接配接
- 從節點發送Ping信号，主節點傳回Pong，兩邊能互相通信
- 連接配接建立後，主節點将所有資料發送給從節點（資料同步）
- 主節點把目前的資料同步給從節點後，便完成了複制的建立過程。接下來，主節點就會持續的把寫指令發送給從節點，保證主從資料一緻性。
Redis的資料同步過程：
redis2.8之前使用sync[runId][offset]同步指令，redis2.8之後使用psync[runId][offset]指令。
兩者不同在于，sync指令僅支援全量複制過程，psync支援全量和部分複制。
介紹同步之前，先介紹幾個概念：
runId：每個redis節點啟動都會生成唯一的uuid，每次redis重新開機後，runId都會發生變化。
offset：主節點和從節點都各自維護自己的主從複制偏移量offset，當主節點有寫入指令時，offset=offset+指令的位元組長度。從節點在收到主節點發送的指令後，也會增加自己的offset，并把自己的offset發送給主節點。這樣，主節點同時儲存自己的offset和從節點的offset，通過對比offset來判斷主從節點資料是否一緻。
repl_backlog_size：儲存在主節點上的一個固定長度的先進先出隊列，預設大小是1MB。
- 主節點發送資料給從節點過程中，主節點還會進行一些寫操作，這時候的資料存儲在複制緩沖區中。從節點同步主節點資料完成後，主節點将緩沖區的資料繼續發送給從節點，用于部分複制。
- 主節點響應寫指令時，不但會把命名發送給從節點，還會寫入複制積壓緩沖區，用于複制指令丢失的資料補救。
上面是psync的執行流程：
從節點發送psync[runId][offset]指令，主節點有三種響應：
- FULLRESYNC：第一次連接配接，進行全量複制
- CONTINUE：進行部分複制
- ERR：不支援psync指令，進行全量複制
全量複制和部分複制的過程
上面是全量複制的流程。主要有以下幾步：
- 從節點發送psync ? -1指令（因為第一次發送，不知道主節點的runId，是以為?，因為是第一次複制，是以offset=-1）。
- 主節點發現從節點是第一次複制，傳回FULLRESYNC {runId} {offset}，runId是主節點的runId，offset是主節點目前的offset。
- 從節點接收主節點資訊後，儲存到info中。
- 主節點在發送FULLRESYNC後，啟動bgsave指令，生成RDB檔案（資料持久化）。
- 主節點發送RDB檔案給從節點。到從節點加載資料完成這段期間主節點的寫指令放入緩沖區。
- 從節點清理自己的資料庫資料。
- 從節點加載RDB檔案，将資料儲存到自己的資料庫中。-如果從節點開啟了AOF，從節點會異步重寫AOF檔案。
關于部分複制有以下幾點說明：
- 部分複制主要是Redis針對全量複制的過高開銷做出的一種優化措施，使用psync[runId][offset]指令實作。當從節點正在複制主節點時，如果出現網絡閃斷或者指令丢失等異常情況時，從節點會向主節點要求補發丢失的指令資料，主節點的複制積壓緩沖區将這部分資料直接發送給從節點，這樣就可以保持主從節點複制的一緻性。補發的這部分資料一般遠遠小于全量資料。
- 主從連接配接中斷期間主節點依然響應指令，但因複制連接配接中斷指令無法發送給從節點，不過主節點内的複制積壓緩沖區依然可以儲存最近一段時間的寫指令資料。
- 當主從連接配接恢複後，由于從節點之前儲存了自身已複制的偏移量和主節點的運作ID。是以會把它們當做psync參數發送給主節點，要求進行部分複制。
- 主節點接收到psync指令後首先核對參數runId是否與自身一緻，如果一緻，說明之前複制的是目前主節點；之後根據參數offset在複制積壓緩沖區中查找，如果offset之後的資料存在，則對從節點發送+COUTINUE指令，表示可以進行部分複制。因為緩沖區大小固定，若發生緩沖溢出，則進行全量複制。
- 主節點根據偏移量把複制積壓緩沖區裡的資料發送給從節點，保證主從複制進入正常狀态。
Redis主從複制會存在以下問題：
- 一旦主節點當機，從節點晉升為主節點，同時需要修改應用方的主節點位址，還需要指令所有從節點去複制新的主節點，整個過程需要人工幹預。
- 主節點的寫能力受到單機的限制。
- 主節點的存儲能力受到單機的限制。
- 原生複制的弊端在早期的版本中也會比較突出，比如：redis複制中斷後，從節點會發起psync。此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時，可能會造成毫秒或秒級的卡頓。
是以用哨兵解決以上問題。
哨兵的功能
Redis Sentinel（哨兵）主要功能包括主節點存活檢測、主從運作情況檢測、自動故障轉移、主從切換。Redis Sentinel最小配置是一主一從。
Redis的Sentinel系統可以用來管理多個Redis伺服器，該系統可以執行以下四個任務：
- 監控：不斷檢查主伺服器和從伺服器是否正常運作。
- 通知：當被監控的某個redis伺服器出現問題，Sentinel通過API腳本向管理者或者其他應用程式發出通知。
- 自動故障轉移：當主節點不能正常工作時，Sentinel會開始一次自動的故障轉移操作，它會将與失效主節點是主從關系的其中一個從節點更新為新的主節點，并且将其他的從節點指向新的主節點，這樣人工幹預就可以免了。
- 配置提供者：在Redis Sentinel模式下，用戶端應用在初始化時連接配接的是Sentinel節點集合，從中擷取主節點的資訊。
哨兵的原理
1、每個Sentinel節點都需要定期執行以下任務：每個Sentinel以每秒一次的頻率，向它所知的主伺服器、從伺服器以及其他的Sentinel執行個體發送一個PING指令。（如上圖）
2、如果一個執行個體距離最後一次有效回複PING指令的時間超過down-after-milliseconds所指定的值，那麼這個執行個體會被Sentinel标記為主觀下線。（如上圖）
3、如果一個主伺服器被标記為主觀下線，那麼正在監視這個伺服器的所有Sentinel節點，要以每秒一次的頻率确認主伺服器的确進入了主觀下線狀态。
4、如果一個主伺服器被标記為主觀下線，并且有足夠數量的Sentinel（至少要達到配置檔案指定的數量）在指定的時間範圍内同意這一判斷，那麼這個主伺服器被标記為客觀下線。
5、一般情況下，每個Sentinel會以每10秒一次的頻率向它已知的所有主伺服器和從伺服器發送INFO指令，當一個主伺服器被标記為客觀下線時，Sentinel向下線主伺服器的所有從伺服器發送INFO指令的頻率，會從10秒一次改為每秒一次。
6、Sentinel和其他Sentinel協商客觀下線的主節點的狀态，如果處于SDOWN狀态，則投票自動選出新的主節點，将剩餘從節點指向新的主節點進行資料複制。
7、當沒有足夠數量的Sentinel同意主伺服器下線時，主伺服器的客觀下線狀态就會被移除。當主伺服器重新向Sentinel的PING指令傳回有效回複時，主伺服器的主觀下線狀态就會被移除。
點選關注，第一時間了解華為雲新鮮技術~