---

以下是本篇文章正文內容

一、哨兵是什么？

哨兵巡查監控后臺master主機是否故障，如果故障了根據投票數自動將某一個從庫轉換為新主庫，繼續對外服務，俗稱無人值守運維

作用：監控redis運行狀態，包括master和slave，當master down機時，能自動將slave切換成新master

哨兵的四個功能

• 主從監控
  • 監控主從redis庫運行是否正常
• 消息通知
  • 哨兵可以將故障轉移的結果發送到客戶端
• 故障轉移
  • 如果master異常，則會進行主從切換，將其中一個slave作為新master
• 配置中心
  • 客戶端通過連接哨兵來獲得當前Redis服務的主節點地址

Redis Sentinel架構
客戶端通過哨兵集群訪問redis 主從復制架構，哨兵集群對主從復制進行監視

本案例架構如下

• 3個哨兵
  • 自動監控和維護集群，不存放數據，只是監控
• 1主2從
  • 用于數據讀取和存放
  • 主機后續可能會變成從機，需要設置訪問新主機的密碼，需要在主機conf文件設置masterauth項訪問密碼為111111,

二、 哨兵sentinel文件參數

• bind 服務監聽地址，用于客戶端連接
• daemonize 是否以后臺daemon方式運行
• protected-mode 安全保護模式
• port 端口
• logfile 日志文件路徑
• pidfile pid日志路徑
• dir 工作目錄
• sentiel monitor < master > < ip > < redis-port > < quorm >
  • 設置要監控的master
  • quorm 表示最少有幾個哨兵認可客觀下線，同意故障遷移的法定票數

網絡是不可靠的，有時候一個sentinel會因為網絡堵塞而誤以為一個master redis已經死掉了，在sentinel集群環境下需要多個sentinel互相溝通來確認某個master是否真的死了，
quorum這個參數是進行客觀下線的一個依據，意思是至少有quorum個sentinel認為這個master有故障，才會對這個master進行下線以及故障轉移。
因為有的時候，某個sentinel節點可能因為自身網絡原因，導致無法連接master，而此時master并沒有出現故障，所以，這就需要多個sentinel都一致認為該master有問題，才可以進行下一步操作，這就保證了公平性和高可用。

• sentiel auth-pass 通過密碼連接master

可以直接把以上參數新建一個文件sentiel.conf寫進redis工作的目錄（即redis.conf所在的目錄）
本案例有三個哨兵，需要新建三個sentiel.conf文件

啟動主從redis后，啟動哨兵

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

Tip：一個哨兵可以同時監控多個redis，只需將配置文件中這些參數進行調整，需要時候可以另行搜索學習。

三、 模仿主機redis宕機

關閉6379主機redis服務器，模仿master掛了

• 兩臺從機的數據不會丟失

• 會從其他兩臺從機選出一個新的master

• 掛掉的master重連回來，直接變成新master的從機

• 本案例中的 sentinel26379.conf、sentinel26380.conf、sentinel26381.conf會在運行中進行動態更改，在conf文件末尾自動添加主從redis所需要的配置

• 在master-slave切換中，master的conf文件中會自動多一行slaveof的配置

四、哨兵運行流程和選舉原理

當一個主從配置中的master失效之后，sentinel可以選舉出一個新的master
用于自動接替原master的工作，主從配置中的其他redis服務器自動指向新的master同步數據。一般建議sentinel采取奇數臺，防止某一臺sentinel無法連接到master導致誤切換

SDOWN主觀下線

SDOWN 是單個sentinel 自己主觀上檢測到的關于master的失效狀態，從sentinel的角度來看，如果發送了PING心跳后，在timeout時間內沒有收到合法的回復，就達到了SDOWN的條件

sentinel配置文件中的down-after-milliseconds 設置了判斷主觀下線的時間長度

sentinel down-after-milliseconds <masterName> <timeout>

ODOWN客觀下線

ODOWN需要一定數量的sentinel，多個哨兵達成一致意見才能認為一個master客觀上已經宕機

這就用到了二、 哨兵sentinel文件參數中的sentiel monitor < master > < ip > < redis-port > < quorm >命令

quorm 表示最少有幾個哨兵認可客觀下線，同意故障遷移的法定票數

• 選舉出領導者哨兵
  當主節點被判斷客觀下線以后，各個哨兵節點會進行協商，先選舉出一個領導者哨兵節點并由該領導者節點進行failover（故障遷移）

  • Raft算法 選出領導者節點

監視該主節點的所有哨兵都有可能被選為領導者，選舉使用的算法是Raft算法;
Raft算法的基本思路是先到先得:即在一輪選舉中，哨兵A向B發送成為領導者的申請，如果B沒有同意過其他哨兵，則會同意A成為領導者

• 由領導者節點開始推動故障切換并選出一個新master

  • 某個slave 成為新 master
  • 其它slave自動進行相關配置和命令修改
  • 老master回來也變為slave

• 選舉新master的過程：

  • 優先級高的成為新master
  • 否則是復制偏移量大的成為新master（即誰的復制的數據多）
  • 否則看RunID，最小的為新master

以上的failover都是sentinel自己獨立完成，完全無需人工干預

五、 使用建議

• 哨兵節點的數量應為多個，哨兵本身應該集群，保證高可用
• 哨兵節點的數量應該是奇數個（這是從投票機制考慮，避免相同票數導致不能決定SDOWN主觀下線）
• 各個哨兵節點的配置應該一致
• 如果哨兵節點部署在Docker等容器里，要注意端口的正確映射
• 哨兵集群+主從復制，并不能保證數據零丟失（因為選舉機制會有時間間隔，導致寫入操作的丟失）