文章目錄
哨兵模式
什麼是哨兵
實作哨兵模式
1.配置一主兩從
2.哨兵模式配置
3.一個哨兵監控多個Redis主從系統
實作原理
主觀下線
客觀下線
選舉領頭哨兵
故障恢複
在主從模式的Redis系統中，從資料庫在整個系統中起到了資料 備援備份和 讀寫分離的作用，但是當資料庫遇到異常中斷服務後，我們隻能通過手動的方式選擇一個從資料庫來升格為主資料庫，顯然這種方式很麻煩需要人工介入，這時通過哨兵模式可以實作自動化的系統監控和故障恢複。
| 序号 | 功能 |
| 1 | 監控主資料庫和從資料庫是否正常運作 |
| 2 | 主資料庫出現故障時自動将從資料庫轉換為主資料庫 |
哨兵是一個獨立的程序，使用哨兵的典型結構圖如下:
在一主多從的Redis系統中，可以使用多個哨兵進行監控任務以保證系統的問題。
主伺服器端口号6379，兩個從伺服器端口分别為:6380和6381.
主伺服器 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=84,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=84,lag=1 從伺服器 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up 從伺服器 6381
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up 修改和redis.conf同級目錄下的sentinel.conf檔案.
sentinel monitor mymaster 127.0.0.1 6380 1
# sentinel monitor master-name ip redis-port quorum | 指令 | 用例 | 說明 |
| master-name | mymaster | 要監控的主資料庫的名稱，可以自定義， 組成大小寫字母，數字和". - _"組成 |
| ip | 127.0.0.1 | 主資料庫(master)的位址 |
| redis-port | 6379 | 主資料庫的端口 |
| quorum | 最低通過的票數 |
啟動哨兵模式:
src/redis-sentinel sentinel.conf 哨兵模式隻需要配置其監控的主資料庫即可，哨兵會自動發現所有複制該資料庫的從資料庫。
關閉6379master測試
檢視6379狀态
關閉6379等待一會檢視哨兵程序界面
當看到如上圖的資訊後，我們再檢視6380的時候，發現該節點已經變成了master了。
再啟動6379我們發現該執行個體依然是slave并不會改變
配置
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel monitor othermaster 192.168.88.60 6380 4 監控不同資料庫使用不同的配置參數:
sentinel down-after-millisenconds mymaster 60000
sentinel down-after-millisenconds othermaster 10000 哨兵啟動後會與要監控的主資料庫建立兩條連接配接
和主資料庫連接配接建立完成後，哨兵會使用連接配接2發送如下指令:
每10秒鐘哨兵會向主資料庫和從資料庫發送INFO 指令
每2秒鐘哨兵會向主資料庫和從資料的_sentinel_:hello頻道發送自己的消息。
每1秒鐘哨兵會向主資料、從資料庫和其他哨兵節點發送PING指令。
首先,發送INFO指令會傳回目前資料庫的相關資訊(運作id，從資料庫資訊等)進而實作新節點的自動發現，前面提到的配置哨兵時隻需要監控Redis主資料庫即可，因為哨兵可以借助INFO指令來擷取所有的從資料庫資訊(slave),進而和這兩個從資料庫分别建立兩個連接配接。在此之後哨兵會每個10秒鐘向已知的主從資料庫發送INFO指令來擷取資訊更新并進行相應的操作。
接下來哨兵向主從資料庫的_sentinel_:hello 頻道發送資訊來與同樣監控該資料庫的哨兵分享自己的資訊。發送資訊内容為:
<哨兵的位址>，<哨兵的端口>，<哨兵的運作ID>，<哨兵的配置版本>，
<主資料庫的名字>，<主資料庫的位址>，<主資料庫的端口>，<主資料庫的配置版本> 哨兵通過監聽的_sentinel_:hello頻道接收到其他哨兵發送的消息後會判斷哨兵是不是新發現的哨兵，如果是則将其加入已發現的哨兵清單中并建立一個到其的連接配接(哨兵與哨兵隻會建立用來發送PING指令的連接配接，不會建立訂閱頻道的連接配接)。
實作了自定發現從資料庫和其他哨兵節點後，哨兵要做的就是定時監控這些資料和節點運作情況，每隔一定時間向這些節點發送PING指令來監控。間隔時間和down-after-milliseconds選項有關，down-after-milliseconds的值小于1秒時，哨兵會每隔down-after-milliseconds指定的時間發送一次PING指令，當down-after-milliseconds的值大于1秒時，哨兵會每隔1秒發送一次PING指令。例如:
// 每隔1秒發送一次PING指令
sentinel down-after-milliseconds mymaster 60000
// 每隔600毫秒發送一次PING指令
sentinel down-after-milliseconds othermaster 600 當超過down-after-milliseconds指定時間後，如果被PING的資料庫或節點仍然未回複，則哨兵認為其主觀下線(subjectively down),主觀下線表示從目前的哨兵程序看來，該節點已經下線。
在主觀下線後，如果該節點是主資料庫，則哨兵會進一步判斷是否需要對其進行故障恢複，哨兵發送SENTINEL is-master-down-by-addr 指令詢問其他哨兵節點以了解他們是否也認為該主資料庫主觀下線，如果達到指定數量時，哨兵會認為其客觀下線(objectively down),并選舉領頭的哨兵節點對主從系統發起故障恢複。這個指定數量就是前面配置的 quorum參數。
sentinel monitor mymaster 127.0.0.1 6380 2 該配置表示隻有當至少有兩個Sentinel節點(包括目前節點)認為該主資料庫主觀下線時，目前哨兵節點才會認為該主資料庫客觀下線。接下來選舉領頭哨兵。
目前哨兵雖然發現了主資料客觀下線，需要故障恢複，但故障恢複需要由領頭哨兵來完成。這樣來保證同一時間隻有一個哨兵來執行故障恢複，選舉領頭哨兵的過程使用了Raft算法，具體過程如下:
發現主資料庫客觀下線的哨兵節點(A)向每個哨兵節點發送指令，要求對象選擇自己成為領頭哨兵
如果目标哨兵節點沒有選過其他人，則會同樣将A設定為領頭哨兵
如果A發現有超過半數且超過quorum參數值的哨兵節點同樣選擇自己成為領頭哨兵，則A成功成為領頭哨兵
當有多個哨兵節點同時參選領頭哨兵，則會出現沒有任何節點當選的可能，此時每個參選節點将等待一個随機事件重新發起參選請求進行下一輪選舉，直到選舉成功。
選出領頭哨兵後，領頭哨兵将會開始對主資料庫進行故障恢複。步驟如下
1、首先領頭哨兵将從停止服務的主資料庫的從資料庫中挑選一個來充當新的主資料庫。
| 挑選依據 | |
| 所有線上的從資料庫中，選擇優先級最高的從資料庫。優先級通過replica-priority參數設定 | |
| 優先級相同，則複制的指令偏移量越大(複制越完整)越優先 | |
| 3 | 如果以上都一樣，則選擇運作ID較小的從資料庫 |
2、選出一個從資料庫後，領頭哨兵将向從資料庫發送SLAVEOF NO ONE指令使其升格為主資料庫，而後領頭哨兵向其他從資料庫發送 SLAVEOF指令來使其成為新主資料庫的從資料庫，最後一步則是更新内部的記錄，将已經停止服務的舊的主資料庫更新為新的主資料庫的從資料庫，使得當其恢複服務時自動以從資料庫的身份繼續服務