Redis如何實現高可用【主從複製+哨兵機制+keepalived】

實現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主從複製如何配置呢？

1.  修改從服務器redis/conf中的redis.conf文件
2.  修改IP地址和端口號爲主服務器的IP和端口
3.  slaveof 10.211.55.9 6379
4.  masterauth 123456 --- 若是主redis服務器配置了密碼,則須要配置

只須要配置從服務器的redis.conf便可，主服務器無需配置。驗證是否成功能夠經過一、先登陸主服務器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(自動重啓)，若重啓屢次仍不成功，能夠經過郵件短信等方式通知。