一、Redis的高可用策略（主從策略）

1. 基本概念

高可用（High Availability），是當一臺伺服器停止服務後對於業務及使用者毫
無影響。 停止服務的原因可能由於網絡卡、
路由器、機房、CPU負載過高、
記憶體溢位、自然災害等不可預期的原因導致，在很多時候也稱單點問題。

主備方式（簡單情景）
這種通常是一臺主機、一臺或多臺備機，在正常情況下主機對外提供服務，
並把資料同步到備機，當主機宕機後，備機立刻開始服務。 
Redis HA中使用比較多的是keepalived，它使主機備機對外提供同一個虛擬IP，
客戶端通過虛擬IP進行資料操作，正常期間主機一直對外提供服務，
宕機後VIP自動漂移到備機上。優點是對客戶端毫無影響，仍然通過VIP操作。 
缺點也很明顯，在絕大多數時間內備機是一直沒使用，被浪費著的。

主從方式（推薦）
這種採取一主多從的辦法，主從之間進行資料同步。 當Master宕機後，
通過選舉演算法(Paxos、Raft)從slave中選舉出新Master繼續對外提供服務，
主機恢復後以slave的身份重新加入。 主從另一個目的是進行讀寫分離，
這是當單機讀寫壓力過高的一種通用型解決方案。 
其主機的角色只提供寫操作或少量的讀，把多餘讀請求通過負載均
衡演算法分流到單個或多個slave伺服器上。

缺點是主機宕機後，
Slave雖然被選舉成新Master了，
但對外提供的IP服務地址卻發生變化了，意味著會影響到客戶端。
 解決這種情況需要一些額外的工作，在當主機地址發生變化後及時通知到客戶端，
 客戶端收到新地址後，使用新地址繼續傳送新請求。

方案選擇
主備（keepalived）方案配置簡單、人力成本小，在資料量少、
壓力小的情況下推薦使用。 如果資料量比較大，不希望過多浪費機器，
還希望在宕機後，做一些自定義的措施，比如報警、記日誌、資料遷移等操作，
推薦使用主從方式，因為和主從搭配的一般還有個管理監控中心。
 

2. 主從拓撲

Redis的主從拓撲支援單層或者多層結構，可分為一主一從，一主多從，樹狀主從。
(1).一主一從：用於主節點故障轉移從節點，當主節點的“寫”命令併發高
且需要持久化，可以只在從節點開啟AOF（主節點不需要），
這樣即保證了資料的安全性，也避免持久化對主節點的影響。

(2).一主多從：針對“讀”較多的場景，“讀”由多個從節點來分擔，但節點越多，主節點同步到多節點的次數也越多，影響頻寬，也加重主節點的負擔。

(3).樹狀主從：一主多從的缺點（主節點推送次數多壓力大）可用些方案解決，主節點只推送一次資料到從節點1，再由從節點2推送到11，減輕主節點推送的壓力。

Redis的資料同步方式

同步方式：當主機收到客戶端寫操作後，以同步方式把資料同步到從機上，當從機也成功寫入後，主機才返回給客戶端成功，也稱資料強一致性。 很顯然這種方式效能會降低不少，當從機很多時，可以不用每臺都同步，主機同步某一臺從機後，從機再把資料分發同步到其他從機上，這樣提高主機效能分擔同步壓力。 在redis中是支援這楊配置的，一臺master，一臺slave，同時這臺salve又作為其他slave的master。
非同步方式：主機接收到寫操作後，直接返回成功，然後在後臺用非同步方式把資料同步到從機上。 這種同步效能比較好，但無法保證資料的完整性，比如在非同步同步過程中主機突然宕機了，也稱這種方式為資料弱一致性。

3.哨兵機制

前面介紹了主從機制，但是從運維角度來看，主節點出現了問題我們還需要通過人工干預的方式把從節點設為主節點，還要通知應用程式更新主節點地址，這種方式非常繁瑣笨重， 而且主節點的讀寫能力都十分有限，有沒有較好的辦法解決這兩個問題，哨兵機制就是針對第一個問題的有效解決方案，第二個問題則有賴於叢集！哨兵的作用就是監控Redis系統的執行狀況，其功能主要是包括以下三個：

監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
提醒(Notification): 當被監控的某個 Redis出現問題時,哨兵(sentinel) 可以通過 API 向管理員或者其他應用程式傳送通知。
自動故障遷移(Automatic failover): 當主資料庫出現故障時自動將從資料庫轉換為主資料庫。

哨兵的原理：Redis哨兵的三個定時任務，Redis哨兵判定一個Redis節點故障不可達主要就是通過三個定時監控任務來完成的：

1.每隔10秒每個哨兵節點會向主節點和從節點發送"info replication"
命令來獲取最新的拓撲結構

每隔2秒每個哨兵節點會向Redis節點的_sentinel_:hello頻道傳送
自己對主節點是否故障的判斷以及自身的節點資訊，
並且其他的哨兵節點也會訂閱這個頻道來了解其他哨兵節
點的資訊以及對主節點的判斷

3.每隔1秒每個哨兵會向主節點、從節點、其他的哨兵節點發送一個 
“ping” 命令來做心跳檢測

如果在定時Job3檢測不到節點的心跳，會判斷為“主觀下線”。如果該節點還是主節點那麼還會通知到其他的哨兵對該主節點進行心跳檢測，這時主觀下線的票數超過了數時，那麼這個主節點確實就可能是故障不可達了，這時就由原來的主觀下線變為了“客觀下線”。

故障轉移和Leader選舉
如果主節點被判定為客觀下線之後，就要選取一個哨兵節點來完成後面的故障轉移工作，選舉出一個leader，這裡面採用的選舉演算法為Raft。選舉出來的哨兵leader就要來完成故障轉移工作，也就是在從節點中選出一個節點來當新的主節點，這部分的具體流程可參考引用.
深入理解Redis哨兵搭建及原理