Redis哨兵叢集模式
一、引言 上一篇文章我們詳細的講解了Redis的主從叢集模式，其實這個叢集模式配置很簡單，只需要在Slave的節點上進行配置，Master主節點的配置不需要做任何更改，但是有一點，Master和Slave兩個節點的持久化配置儘量保持一致，否則會有奇怪的問題出現。從今天開始我們開始講Redis叢集模式的第二模式，也就是“哨兵”模式，該模式是從Redis的2.6版本開始提供的，但是當時這個版本的模式是不穩定的，直到Redis的2.8版本以後，這個哨兵模式才穩定下來，在生產環境中，如果想要使用Redis的哨兵模式，也會盡量使用Redis的2.8版本之後的版本。無論是主從模式，還是哨兵模式，這兩個模式都有一個問題，不能水平擴容，並且這兩個模式的高可用特性都會受到Master主節點記憶體的限制。還有一點，實現哨兵模式的配置也不簡單，甚至可以說有些繁瑣，所以在工業場景裡這兩個模式都不建議使用，如果要使用必須有相關的問題的解決方案，以免後續帶來的問題。二、Redis Sentinel簡介
1.1、### NETWORK 設定： bind 192.168.127.128 //繫結IP地址，可以通過ifconfig 獲取Ip地址(在Linux系統下) port 6379 //保持預設值，也可以修改 timeout 30 //Client 端空閒斷開連線的時間 1.2、### GENERAL 設定： daemonize yes //預設值是no，把值修改為yes，以後臺模式執行 logfile /root/application/program/redis-tool/logs/redis.log //日誌檔案的位置 1.3、### SNAPSHOTTING 設定： dir /root/application/program/redis-tool/datas //SNAPSHOTTING檔案的路徑 1.4、### APPEND ONLY MODE 設定： appendonly yes //預設值是No，意思是不使用AOF增量持久化的方式，使用RDB全量持久化的方式。把No值改成Yes，使用AOF增量持久化的方式 appendfsync always
2、###### Slave Config（redis.conf）
2.1、### NETWORK 設定： bind 192.168.127.129 //繫結IP地址，可以通過ifconfig 獲取Ip地址(在Linux系統下) port 6379 //保持預設值，也可以修改 timeout 30 //Client 端空閒斷開連線的時間 2.2、### GENERAL 設定： daemonize yes //預設值是no，把值修改為yes，以後臺模式執行 logfile /root/application/program/redis/logs/redis.log //日誌檔案的位置 2.3、### SNAPSHOTTING 設定： dir /root/application/program/redis/datas //SNAPSHOTTING檔案的路徑 2.4、### REPLICATION 設定： slaveof 192.168.127.128 6379 //主伺服器的Ip地址和Port埠號 slave-serve-stale-data no //如果slave 無法與master 同步，設定成slave不可讀，方便監控指令碼發現問題。 2.5、### APPEND ONLY MODE 設定： appendonly yes //預設值是No，意思是不使用AOF增量持久化的方式，使用RDB全量持久化的方式。把No值改成Yes，使用AOF增量持久化的方式 appendfsync always
3、###### Sentinel Config（sentinel.conf，192.168.127.129 Slave從伺服器）
3.1、 ### Port 設定：
port 26379 //哨兵埠號保持不變，可以修改，但是我沒有修改
3.2、### dir 設定：
dir /root/application/program/redis/sentinel/ //哨兵程式的日誌路徑
3.3、### Sentinel Monitor 設定：
sentinel monitor mymaster 192.168.127.129 6379 1
3.4、### Down-After-Milliseconds 設定：
sentinel down-after-milliseconds mymaster 5000
//哨兵程式每5秒檢測一次Master是否正常
3.5、### Parallel-Syncs 設定：
sentinel parallel-syncs mymaster 1
3.5、### Failover-Timeout 設定：
sentinel failover-timeout mymaster 60000
3.5、### 啟動：redis-sentinel
redis-server sentinel.conf --sentinel & //(&有這可以Ctrl +C退到命令列，沒有這個就直接退出哨兵程序)
redis-sentinel /path/to/sentinel.conf & //對於 redis-sentinel 程式， 你可以用以下命令來啟動 Sentinel 系統
3.6、### 關閉：redis-sentinel
pkill redis-server //這個會關掉Redis伺服器和Sentinel（哨兵）程序
kill 程序號 //可以關掉指定程序號的程序
4、###### 模式測試 4.1、在Sentinel.conf配置檔案設定 sentinel monitor： 
4.2、在Sentinel.conf配置檔案設定 sentinel down-after-milliseconds： 
4.3、在Sentinel.conf配置檔案設定 sentinel parallel-syncs： 
4.4、Master 主伺服器的配置詳情： 
4.5、Slave 從伺服器配置詳情： 
4.6、啟動Sentinel（哨兵）程序，開始對Master主伺服器進行監控：
4.7、我們人為模仿Master主伺服器宕機：
4.8、實現Master主伺服器和Slave從伺服器的切換：
4.9、主從切換後，主伺服器變成了Slave 從伺服器，詳情如下：
4.10、主從切換後，從伺服器變成了Master 主伺服器，詳情如下： 
注意： ① INFO sentinel的基本狀態資訊 ②SENTINEL masters 列出所有被監視的主伺服器，以及這些主伺服器的當前狀態 ③ SENTINEL slaves 列出給定主伺服器的所有從伺服器，以及這些從伺服器的當前狀態 ④SENTINEL get-master-addr-by-name 返回給定名字的主伺服器的 IP 地址和埠號 ⑤SENTINEL reset 重置所有名字和給定模式 pattern 相匹配的主伺服器。重置操作清除主伺服器目前的所有狀態， 包括正在執行中的故障轉移， 並移除目前已經發現和關聯的， 主伺服器的所有從伺服器和 Sentinel 。 ⑥SENTINEL failover 當主伺服器失效時， 在不詢問其他 Sentinel 意見的情況下， 強制開始一次自動故障遷移，但是它會給其他sentinel傳送一個最新的配置，其他sentinel會根據這個配置進行更新四、主觀下線和客觀下線 下面我們來解釋一下兩個“下線”的概念，一個是“主觀下線”，另一個就是“客觀下線”。 主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 例項對伺服器做出的下線判斷。 客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 例項在對同一個伺服器做出 SDOWN 判斷，並且通過 SENTINEL is-master-down-by-addr 命令互相交流之後，得出的伺服器下線判斷。（一個 Sentinel 可以通過向另一個 Sentinel 傳送 SENTINEL is-master-down-by-addr 命令來詢問對方是否認為給定的伺服器已下線。） 如果一個伺服器沒有在 master-down-after-milliseconds 選項所指定的時間內，對向它傳送 PING 命令的 Sentinel（哨兵）程序返回一個有效回覆（valid reply），那麼 Sentinel（哨兵）程序就會將這個伺服器標記為主觀下線。 伺服器對 PING 命令的有效回覆可以是以下三種回覆的其中一種： 1、返回 +PONG 。 2、返回 -LOADING 錯誤。 3、返回 -MASTERDOWN 錯誤。 如果伺服器返回除以上三種回覆之外的其他回覆，又或者在指定時間內沒有回覆 PING 命令，那麼 Sentinel（哨兵）程序認為伺服器返回的回覆無效（non-valid）。 如果一個伺服器在 master-down-after-milliseconds 毫秒內，一直返回無效回覆才會被 Sentinel 標記為主觀下線。 舉個例子，如果 master-down-after-milliseconds 選項的值為 30000 毫秒（30 秒），那麼只要伺服器能在每 29 秒之內返回至少一次有效回覆， 這個伺服器就仍然會被認為是處於正常狀態的。 從“主觀下線”狀態切換到“客觀下線”狀態並沒有使用嚴格的法定人數演算法（strong quorum algorithm），而是使用了流言協議，該協議解釋為：如果 Sentinel（哨兵）程序在給定的時間範圍內，從其他 Sentinel（哨兵）程序那裡接收到了足夠數量的主伺服器下線報告， 那麼 Sentinel（哨兵）程序就會將主伺服器的狀態從“主觀下線”改變為“客觀下線”。如果之後其他 Sentinel（哨兵）程序不再報告主伺服器已下線，那麼“客觀下線”狀態就會被移除。 “客觀下線”條件只適用於主伺服器：對於任何其他型別的 Redis 例項， Sentinel（哨兵）程序在將它們判斷為下線前不需要進行協商，所以Slave從伺服器或者其他 Sentinel（哨兵）程序永遠不會達到“客觀下線”條件。 只要有一個 Sentinel（哨兵）程序發現某個主伺服器進入了“客觀下線”狀態，這個 Sentinel（哨兵）程序就可能會被其他 Sentinel（哨兵）程序推選出，並對失效的主伺服器執行自動故障遷移操作。五、Sentinel（哨兵）配置檔案簡介 在Redis的原始碼中包含了一個名為 sentinel.conf 的檔案， 這個檔案就是帶有註釋的Sentinel（哨兵）的配置檔案的示例。 如果想要執行一個“哨兵”程式，以下配置項是最少配置： sentinel monitor mymaster 127.0.0.1 6379 1 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 第一行配置表示 Sentinel（哨兵）程序去監視一個名為 mymaster 的主伺服器，這個主伺服器的 IP 地址為 127.0.0.1 ， 埠號為 6379，而將這個主伺服器判斷為失效至少需要 1 個 Sentinel（哨兵）程序的同意。如果在架構系統中已經配置類多個Sentinel（哨兵）程序，在同意“Master主伺服器”下線的 Sentinel（哨兵）程序的數量不達標的情況下，Sentinel（哨兵）程序就不會執行自動故障遷移。在設定多Sentinel（哨兵）程序的情況下，無論設定多少個 Sentinel（哨兵）程序同意才能判斷一個伺服器失效，一個 Sentinel 都需要獲得架構系統中多數 Sentinel（哨兵）程序的支援， 才能發起一次自動故障遷移，並預留一個給定的配置紀元 （configuration Epoch ，一個配置紀元就是一個新主伺服器配置的版本號）。如果您只配置了一個Sentinel（哨兵）程序來做監控，那一個Sentinel（哨兵）程序也可以決定“Master主伺服器”是否下線。 其他選項的基本格式如下：sentinel <選項的名字> <主伺服器的名字> <選項的值> 配置選項的解釋如下： 1、down-after-milliseconds ： Sentinel（哨兵）程序判斷伺服器已經掉線所需的毫秒數。 如果被監控的伺服器在給定的毫秒數之內，並沒有返回 Sentinel（哨兵）程序傳送的 PING 命令的回覆，或者返回一個錯誤，那麼 Sentinel（哨兵）程序將這個伺服器標記為主觀下線（subjectively down，簡稱 SDOWN ）。如果在架構系統中配置了多個Sentinel（哨兵）程序的情況下，只有一個Sentinel（哨兵）程序將伺服器標記為主觀下線並不一定會引起伺服器的自動故障遷移，只有在足夠數量的 Sentinel（哨兵）程序都將一個伺服器標記為主觀下線之後，伺服器才會被標記為客觀下線（objectively down， 簡稱 ODOWN ），這時才回執行自動故障遷移。另外一種情況是，在架構系統中只配置了一個Sentinel（哨兵）程序的話，那這Sentinel（哨兵）程序也可以決定被監控的伺服器的是否“下線”。 將伺服器標記為客觀下線所需的 Sentinel（哨兵）程序數量由對主伺服器的配置決定。 2、parallel-syncs ：在執行故障轉移時，最多可以有多少個從伺服器同時對新的主伺服器進行同步，這個數字越小，完成故障轉移所需的時間就越長。 如果“Slave從伺服器”被設定為允許使用過期資料集（參見對 redis.conf 檔案中對 slave-serve-stale-data 選項的說明），那麼你可能不希望所有“Slave從伺服器”都在同一時間向新的“Master主伺服器”傳送同步請求， 因為儘管複製過程的絕大部分步驟都不會阻塞“Slave從伺服器”，但“Slave從伺服器”在載入“Master主伺服器”發來的 RDB 檔案時， 仍然會造成“Slave從伺服器”在一段時間內不能處理命令請求，如果全部“Slave從伺服器”一起對新的“Master主伺服器”進行同步， 那麼就可能會造成所有“Slave從伺服器”在短時間內全部不可用的情況出現。 你可以通過將這個值設為 1 來保證每次只有一個Slave從伺服器處於不能處理命令請求的狀態。 3、failover-timeout：實現主從切換，完成故障轉移的所需要的最大時間值。若Sentinel（哨兵）程序在該配置值內未能完成故障轉移的操作（即故障時master/slave自動切換），則認為本次故障轉移操作失敗。 4、notification-script: 指定Sentinel（哨兵）程序檢測到Master-Name所指定的“Master主伺服器”的例項異常的時候，所要呼叫的報警指令碼。該配置項可選，但線上系統建議配置。六、哨兵模式的優缺點 優點： 1、哨兵叢集模式是基於主從模式的，所有主從的優點，哨兵模式同樣具有。 2、主從可以切換，故障可以轉移，系統可用性更好。 3、哨兵模式是主從模式的升級，系統更健壯，可用性更高。 缺點： 1、Redis較難支援線上擴容，在叢集容量達到上限時線上擴容會變得很複雜。為避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費。七、結束 今天就寫到這裡了，Redis的哨兵模式是以主從模式為基礎的，所以說，主從模式擁有的一些缺點，在哨兵模式下也具有。哨兵模式主要是監控Master主伺服器的執行情況，當然也會監控Slave從伺服器的執行情況，如果Master主伺服器發生了故障，該模式可以保證Slave從伺服器順利升級為Master主伺服器繼續提供服務，以此提高系統的高可用性。雖然哨兵模式比主從模式提高了不少系統的高可用性，但是該模式不能水平擴容，不能動態的增、刪節點，這也是限制哨兵模式廣泛應用的主要原因。Redis也看到了這個情況，所在在Redis的3.x以後的版本提供了一個更加強大叢集模式，那就是Cluster叢集模式，這個模式也是我們下一篇文章的主題。