摘要：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命令返回有效回覆時，主伺服器的主觀下線狀態就會被移除。