實現redis高可用機制的一些方法：

保證redis高可用機制需要redis主從複製、redis持久化機制、哨兵機制、keepalived等的支援。

主從複製的作用：資料備份、讀寫分離、分散式叢集、實現高可用、宕機容錯機制等。

redis主從複製原理

首先主從複製需要分為兩個角色：master(主) 和 slave(從) ，注意：redis裡面只支援一個主，不像Mysql、Nginx主從複製可以多主多從。

1、redis的複製功能是支援多個數據庫之間的資料同步。一類是主資料庫（master）一類是從資料庫（slave），主資料庫可以進行讀寫操作，當發生寫操作的時候自動將資料同步到從資料庫，而從資料庫一般是隻讀的，並接收主資料庫同步過來的資料，一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫。

2、通過redis的複製功能可以很好的實現資料庫的讀寫分離，提高伺服器的負載能力。主資料庫主要進行寫操作，而從資料庫負責讀操作。

主從複製全量同步的過程：見下圖

Redis主從複製可以根據是否是全量分為全量同步和增量同步

Redis全量複製一般發生在Slave初始化階段，這時Slave需要將Master上的所有資料都複製一份。

全量同步過程：

1：當一個從資料庫啟動時，會向主資料庫傳送sync命令，

2：主資料庫接收到sync命令後會開始在後臺儲存快照（執行rdb操作），並用快取區記錄後續的所有寫操作

3：當主伺服器快照儲存完成後，redis會將快照檔案傳送給從資料庫。

4：從資料庫收到快照檔案後，會

5:   主伺服器快照發送完畢後開始向從伺服器傳送緩衝區中的寫命令。

6:   從伺服器完成對快照的載入，開始接收命令請求，並執行來自主伺服器緩衝區的寫命令。

增量同步的過程：

Redis增量複製是指slave初始化後開始正常工作時主伺服器發生的寫操作同步到從伺服器的過程。 

增量複製的過程主要是主伺服器每執行一個寫命令就會向從伺服器傳送相同的寫命令，從伺服器接收並執行收到的寫命令。

Redis主從複製全量與增量同步的選擇：

主從伺服器剛剛連線的時候，會先進行全量同步；全同步結束後，再進行增量同步。當然，如果有需要，slave 在任何時候都可以發起全量同步。redis 策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。

redis主從複製如何配置呢？

修改從伺服器redis/conf中的redis.conf檔案

修改IP地址和埠號為主伺服器的IP和埠
slaveof 10.211.55.9 6379 
 
masterauth 123456--- 如果主redis伺服器配置了密碼,則需要配置

只需要配置從伺服器的redis.conf即可，主伺服器無需配置。驗證是否成功可以通過1、先登入主伺服器redis-cli客戶端，輸入info。若role顯示master、slave0能正常顯示從伺服器的ip，則表示主從服務配置成功，主從複製配置成功了，也同時實現了讀寫分離，不信?你看看試試看你的從伺服器還能不能寫入操作了？答案是：不能。從伺服器只有讀操作！

Redis哨兵機制

哨兵機制需要主從複製的支援。

Redis的哨兵(sentinel) 系統用於管理多個 Redis 伺服器,該系統執行以下三個任務:

·        監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。

·        提醒(Notification):當被監控的某個Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程式傳送通知。

·        自動故障遷移(Automatic failover):當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 並讓失效Master的其他Slave改為複製新的Master; 當客戶端試圖連線失效的Master時,叢集也會向客戶端返回新Master的地址,使得叢集可以使用Master代替失效Master。

哨兵(sentinel) 是一個分散式系統,你可以在一個架構中執行多個哨兵(sentinel) 程序,這些程序使用流言協議(gossipprotocols)來接收關於Master是否下線的資訊,並使用投票協議(agreement protocols)來決定是否執行自動故障遷移,以及選擇哪個Slave作為新的Master.

每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時傳送訊息,以確認對方是否”活”著,如果發現對方在指定時間(可配置)內未迴應,則暫時認為對方已掛(所謂的”主觀認為宕機” Subjective Down,簡稱sdown).

若“哨兵群”中的多數sentinel,都報告某一master沒響應,系統才認為該master"徹底死亡"(即:客觀上的真正down機,Objective Down,簡稱odown),通過一定的vote演算法,從剩下的slave節點中,選一臺提升為master,然後自動修改相關配置.

雖然哨兵(sentinel) 釋出為一個單獨的可執行檔案 redis-sentinel ,但實際上它只是一個執行在特殊模式下的 Redis 伺服器，你可以在啟動一個普通 Redis 伺服器時通過給定 --sentinel 選項來啟動哨兵(sentinel).

哨兵(sentinel) 的一些設計思路和zookeeper非常類似

單個哨兵(sentinel)

哨兵模式如何配置?

注意：哨兵機制是redis自帶的功能，不需要接入第三方實現

實現步驟:                                                               哨兵機制埠號預設為26379

配置之前注意防火牆是否關閉

1.修改sentinel.conf配置檔案(該檔案存在於redis安裝包根目錄下)

注意：初次配置，不需要開啟#sentinel monitor mymaster註釋，因為後幾行有預設當臺伺服器為主伺服器

原配置：sentinel monitor mymaster 127.0.0.1 6379 2 通過這句來修改為：

sentinel monitor mymaster  10.211.55.3  6379  1   #主伺服器名稱 IP 埠號 選舉次數(redis叢集伺服器不多時可以配置成1)

2.修改下一行：sentinel auth-pass mymaster 123456 # 第一個引數mymaster為主節點名稱，123456為主伺服器密碼。

3. 修改心跳檢測 5000毫秒【預設為30秒】

sentinel down-after-milliseconds mymaster 5000

4.sentinel parallel-syncs mymaster 2 --- 指定了在執行故障轉移時，最多可以有多少個從Redis例項在同步新的主例項，在從Redis例項較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長

5. 啟動哨兵模式【cd到redis安裝根目錄下啟動，因為需要執行redis-server】

./redis-server sentinel.conf --sentinel &

啟動後如果列印+ monitor master 主節點名 ip     和    +slave slave  ip則表示啟動成功

6.可以通過模擬——主伺服器進入redis-cli，輸入shutdown，觀察哨兵所在伺服器日誌列印。原從伺服器本不能寫操作，後由於哨兵自動故障遷移把某一個slave伺服器升級為master伺服器，則該升級後的伺服器又可以進行寫操作。

光靠redis主從複製和哨兵機制不足以實現redis高可用。為什麼呢？

因為若某一節點宕機後，不會實現自動重啟。最穩健實現高可用的做法 :

redis主從複製+哨兵機制(監控、提醒、自動故障遷移)+keepalived(自動重啟)，若重啟多次仍不成功，可以通過郵件簡訊等方式通知。