Redis Sentinel高可用架構

這篇文章主要介紹Redis高可用架構 Redis Sentinel，分别從它是什麼，為什麼使用，自動化過程以及部署等幾個方面說明。

Redis Sentinel 是什麼？

Redis Sentinel是Redis的高可用實作方案，是一個分布式架構，包含了若幹個Sentinel節點和Redis資料節點，每個Sentinel節點會對資料節點和其他Sentinel節點進行監控，當發現節點不可用時，程式會進行自動化處理，不需要人工介入，進而高效解決了Redis的高可用問題。

為什麼要使用？

傳統的主從複制模式将主節點資料改變同步給從節點，這樣作用有兩個：

1. 作為主節點出現故障的備份
2. 降低主節點的「讀」壓力

在主從複制模式下，一旦主節點出現故障，這個過程中需要人工幹預進行故障轉移，由于人工幹預實時性無法得到保證，并且操作過程也容易出現錯誤，增加了整個過程的不便。是以需要引入一個高可用的架構來自動化轉移的整個過程。

自動化過程

轉移過程同主從複制人工幹預邏輯一樣，這裡面我們先看人工幹預過程：

1. 主節點(M)故障，從節點(S1,S2)複制中斷。
2. 執行

   slaveof no one

    選一個S1從節點作為新節點。
3. 更新用戶端redis連結到新的主節點S1，重新開機
4. 從節點S2開始複制主節點S1資料，等待曾經的主節點M恢複，去複制新的主節點S1資料。

Redis sentinel和主從模式差別隻是增加Sentinel節點進行Redis節點監控。

1. 如圖每個Sentinel節點通過定時監控發現主節點出現故障（主關下線）
2. 多個Sentinel節點對主節點故障達成一緻，選出一個上司者負責故障轉移
3. 轉移資料過程同上面「人工幹預」邏輯一緻，隻是是自動化的。
4. 轉移完成後，節點slave-1（或者slave-2）變為主節點，原來的master 變為從節點

從上面看出Redis Sentinel具有監控通知，主節點故障轉移，提供配置（用戶端連接配接Sentinel節點）等功能。

部署上線

這裡我們部署架構使用3個Sentinel節點，1個主節點，2個從節點，組成Redis Sentinel架構。

• 首先我們正常啟動master，slave節點
• 配置sentinel conf 檔案

配置檔案redis_sentinel.conf如下：

port 26379
bind 10.xx.xx.xx
sentinel monitor mymaster 10.xx.xx.xx 6379 2 
# 表示配置需要監控10.xx.xx.xx:6379 
# 2表示至少需要2個Sentinel節點統一， 
# mymaster是主節點别名，防止挂了也可以找到主節點
sentinel auth-pass mymaster password  # 需要的密碼
sentinel config-epoch mymaster 0  #确認mymater SDOWN時長
sentinel down-after-milliseconds mymaster 5000
# mymaster多久不響應認為SDOWN
sentinel failover-timeout mymaster 60000 
# 2次failover切換時間
dir "/etc/redis" # 定義目錄存放
daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"           

• 做service啟動腳本redis-sentinel.sh放在 

  /etc/init.d/

•  并且該腳本可執行

sudo service redis-sentinel start      

一些建議

1. Redis Sentinel的所有節點應該分布在不同的實體機上。