轉載自?https://blog.csdn.net/yswKnight/article/details/78158540

?

一.什么是哨兵機制?

答：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非常類似

二.哨兵模式的配置修改

實現步驟:
1.拷貝到etc目錄
? ??cp sentinel.conf? /usr/local/redis/etc
2.修改sentinel.conf配置文件
? ? sentinel monitor mymast? 192.168.110.133 6379 1? #主節點 名稱 IP 端口號 選舉次數

? #配置主服務器的密碼(如沒設置密碼，可以省略)??
? ?sentinel auth-pass mymaster 123456??
3. 修改心跳檢測 5000毫秒
? ? sentinel down-after-milliseconds mymaster 5000
4. 做多多少合格節點

? ? sentinel parallel-syncs mymaster 2
5. 啟動哨兵模式
? ?./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
6. 停止哨兵模式

注意：

1.當啟動哨兵模式之后，如果你的master服務器宕機之后，哨兵自動會在從redis服務器里面 投票選舉一個master主服務器出來；這個主服務器也可以進行讀寫操作！

2.如果之前宕機的主服務器已經修好，可以正式運行了。那么這個服務器只能進行讀的操作，會自動跟隨由哨兵選舉出來的新服務器！

3.大家可以進入./redis-cli，輸入info，查看你的狀態信息；

?

三、哨兵(Sentinel)總結

?

1、Sentinel的作用：

A、Master?狀態監測

B、如果Master?異常，則會進行Master-slave?轉換，將其中一個Slave作為Master，將之前的Master作為Slave?

C、Master-Slave切換后，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換?

?

?

2、Sentinel的工作方式:

?

1)：每個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他?Sentinel?實例發送一個?PING?命令。

2)：如果一個實例（instance）距離最后一次有效回復?PING?命令的時間超過?down-after-milliseconds?選項所指定的值，?則這個實例會被?Sentinel?標記為主觀下線。?

3)：如果一個Master被標記為主觀下線，則正在監視這個Master的所有?Sentinel?要以每秒一次的頻率確認Master的確進入了主觀下線狀態。?

4)：當有足夠數量的?Sentinel（大于等于配置文件指定的值）在指定的時間范圍內確認Master的確進入了主觀下線狀態，?則Master會被標記為客觀下線?。

5)：在一般情況下，?每個?Sentinel?會以每?10?秒一次的頻率向它已知的所有Master，Slave發送?INFO?命令?。

6)：當Master被?Sentinel?標記為客觀下線時，Sentinel?向下線的?Master?的所有?Slave?發送?INFO?命令的頻率會從?10?秒一次改為每秒一次?。

7)：若沒有足夠數量的?Sentinel?同意?Master?已經下線，?Master?的客觀下線狀態就會被移除。?

若?Master?重新向?Sentinel?的?PING?命令返回有效回復，?Master?的主觀下線狀態就會被移除。
?

最后，如果大家看不太懂，推薦大家看兩個博客，就明白了！

1.http://blog.csdn.net/zbw18297786698/article/details/52891695
2.http://blog.csdn.net/candy_rainbow/article/details/52842402

===========================================================================

心跳檢測

在命令傳播階段，從服務器默認以每秒一次的頻率，向主服務器發送命令：

REPLCONF ACK <replication_offset>?//replication_offset是從服務器當前的復制偏移量。

心跳檢測的作用：檢測主服務器的網絡連接狀態；輔助實現min-slaves選項；檢測命令丟失。

檢測主從服務器的網絡連接狀態

通過向主服務器發送INFO replication命令，可以列出從服務器列表，可以看出從最后一次向主發送命令距離現在過了多少秒。

lag的值應該在0或1之間跳動，如果超過1則說明主從之間的連接有故障。

輔助實現min-slaves選項

Redis可以通過配置防止主服務器在不安全的情況下執行寫命令；

min-slaves-to-write 3

min-slaves-max-lag 10

上面的配置表示：從服務器的數量少于3個，或者三個從服務器的延遲（lag）值都大于或等于10秒時，主服務器將拒絕執行寫命令。這里的延遲值就是上面INFOreplication命令的lag值。

檢測命令丟失

如果因為網絡故障，主服務器傳播給從服務器的寫命令在半路丟失，那么當從服務器向主服務器發送REPLCONF ACK命令時，主服務器將發覺從服務器當前的復制偏移量少于自己的復制偏移量，然后主服務器就會根據從服務器提交的復制偏移量，在復制積壓緩沖區里面找到從服務器缺少的數據，并將這些數據重新發送給從服務器。

主服務器向從服務器補發缺失數據這一操作的原理和部分重同步操作的原理非常相似，它們的區別在于：補發缺失數據操作在主從服務器沒有斷線的情況下執行，而部分重同步操作則在主從服務器斷線并重連之后執行。

?

?

微信掃一掃---打賞

總結

以上是生活随笔為你收集整理的Redis的哨兵机制 或者心跳机制 模式 原理详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。