在redis中，根據不同架構方式可以有不同的故障轉移方案。主要有通過sentinel和集羣兩種方式。
Sentinel架構模式
Sentinel是Redis高可用性的解決方案。在Redis主從架構中，當主服務器發生故障時，不能進行主備切換。而Sentinel產生就是爲了完整redis的故障轉移工作。
sentinel系統工作圖如下：
在啓動sentinel系統以後，sentinel系統會爲其所監視的主從服務器創建命令連接和訂閱連接。
- 命令連接：用於向服務器發送命令，並接收命令回覆。
- 訂閱連接：用於訂閱服務器的_sentinel_:hello頻道。爲了發現未知的新sentinel
Sentinel實例直接則相互創建命令連接，通過命令連接可以向其他Sentinel實例進行信息交換。
通信
建立連接後，Sentinel會以每10s的頻率通過命令連接向被監視的主服務器發送INFO命令，通過分析INFO命令的回覆來獲取主服務器當前信息（主服務本身信息以及從服務器的信息）。
主觀下線和客觀下線
在默認情況下，Sentinel會以每秒一次的頻率向所有與它創建了命令連接的實例發送PING命令，並通過PIING命令的回覆來判斷實例是否在線。在down-after-millseconds選項指定的時間內若得不到有效回覆，Sentinel會將當前實例進入主觀下線狀態。
當Sentinel將一個主服務器判定爲主觀下線狀態時，爲了確認這個服務器是否真的下線了，他會向同樣監視這個服務器的其他Sentinel進行詢問，看他們是否也認爲該主服務器進入下線狀態。當從其他Sentinel那裏接收到足夠數量已下線判斷後，sentinel會將該主服務器判定爲客觀下線狀態。
選舉領頭Sentinel
當一個主服務器被判定爲客觀下線以後，監視這個服務器的各個Sentinel會進行協商，選舉出一個領頭的Sentinel，並由領頭Sentinel對下線主服務器進行故障轉移。
每經過一次選舉，無論選舉成功還是失敗，每隔sentinel實例的配置紀元都會自增1，每個新的紀元中，任何一個sentinel都有可能成爲領頭Sentinel。
選舉過程：
1、當一個源Sentinel向另一個Sentinel發送SENTINEL is-master-down-by-addr<ip,port,epoch,runid>命令，命令中的runid可以爲*,用於檢測客觀下線狀態，爲源sentinel的id時，則用於選舉領頭sentinel。
2、設置局部領頭的Sentinel的規則是先到先得：最先向目標Sentinel發送設置要求的源Sentinel將稱爲目標Sentinel的局部領頭Sentinel，而之後收到的所有設置要求都會被拒絕。
3、當收到目標sentinel的回覆後，會檢查回覆中leader_epoch紀元是否和自己紀元配置相同，如果相同，則取出runid，如果和自己的runid相同，則說明源sentinel已經被目標sentinel選舉爲局部領頭sentinel。
4、如果有某個Sentinel被半數以上的sentinel設置成局部領頭sentinel，那麼這個sentinel將成爲領頭sentinel。
5、如果在給定的時限內，沒有一個sentinel被選舉爲領頭sentinel，那麼將再次進行選舉，配置紀元+1，直到選舉出領頭sentinel。
故障轉移
1、領頭sentinel將從下線的主服務器的所有從服務器中根據一定規則挑選出一個從服務器，將其轉換爲主服務器。
向這個從服務器server2發送slave no one命令，將這個從服務器轉換爲主服務器。在發送完slaveof on one命令之後，領頭sentinel會以每秒一次的頻率向被升級的從服務器發送INFO命令，並觀察回覆後的role信息，當從slave變成master後，說明該server2從服務器已經順利升級爲主服務器了。
2、修改從服務器的複製目標
向其他兩個從服務器發送slaveof<server2.ip,server2.port>命令，使得server2稱爲server3和server4的主服務器。讓他們複製server2的數據。
3、當server1重新啓動後，將舊的主服務器成爲新的主服務器的從服務器
領頭sentinel會向server1發送slaveof命令，使server2成爲server1的主服務器。
以上便是sentinel進行故障轉移的整個流程。sentinel在整個架構中起到了很好的監控和故障轉移的作用。是redis實現高可用的方案之一。