接下來我們就介紹一下哨兵模式，我們會從以下幾個方面進行介紹：
- 哨兵簡介
- 啓用哨兵模式
- 哨兵工作原理
假如master主機“宕機”了，我們要做的就是把宕機的master幹掉，然後從剩餘的slave中選出一個master
下圖是挑選出新的master
在主master宕機到選擇出新的master，中間經歷了什麼。如下：
- 將宕機的master下線
- 找一個slave作爲master
- 通知所有的slave連接新的master
- 啓動新的master與slave
- 全量複製*N+部分複製*N（重啓後有可能是N臺slave全量複製+部分複製）
那麼問題來了……
誰來確認master宕機了？
找一個主？怎麼找法？
修改配置後，原始的主恢復了怎麼辦？
這個時候哨兵就來了
哨兵
哨兵（sentinel）是一個分佈式系統，用於對主從結構中的每臺服務器進行監控，當出現故障時通過投票機制選擇新的master並將所有slave連接到新的master
哨兵的作用
1.監控
不斷的檢查master和slave是否正常運行
Master存活檢測、master與slave運行情況檢測
2.通知（提醒）
當被監控的服務器出現問題時，向其他（哨兵間，客戶端）發送通知
3.自動故障轉移
斷開master與slave連接，選取一個slave作爲master，將其他slave連接到新的master，並告知客戶端新的服務器地址
注意：哨兵也是一臺redis服務器，只是不提供數據服務
通常哨兵配置數量爲單數
配置哨兵
- 配置一拖二主從結構
- 配置三個哨兵（配置相同，端口不同）
參看sentinel.conf
- 啓動哨兵
redis-sentinel sentinel-端口號.conf
查看配置文件
cat sentinel.conf |grep -v “#” |grep -v “^$” > ./conf/sentinel-26379.conf
上面的的命令是過濾掉#的註釋和換行，然後將這個文件中過濾後的內容複製到後面的文件中
哨兵工作原理
階段一：監控階段
用於同步各個節點的狀態信息
獲取各個sentinel的狀態（是否在線）
獲取master的狀態
Master屬性
runid
role：master
各個slave的詳細信息
獲取所有slave的狀態（根據master中的slave信息）
Slave屬性
runid
role：slave
master_host、master_port
offset
……
階段二：通知階段
階段三：故障轉移階段
主觀下線：一臺sentinel認爲掛了
客觀下線：超過半數sentinel認爲掛了
sentinel1認爲master掛了，然後標誌主觀下線，然後它在sentinel圈內傳播，然後sentinel2、sentinel3向master發起呼叫，如果超過半數沒有迴應，則標誌其爲客觀下線。
然後清理隊伍，清理隊伍之前先選擇一個領頭的master
首先會把掛掉的ip、端口發到內部羣裏，然後說一下自己參與過的競選次數，然後告訴別人自己的runid，讓大家選自己，比如1和4同時將信息發到內部羣裏，2先接到誰的就把這一票投給誰。按照這個機制，最後會得到一個投票的結果。如果沒有得到一個好的結果，然後競選次數增加一，繼續競選
發送：SENTINEL is-master-down-by-addr ……
掛掉的ip
掛掉的端口
競選次數
自己的runid
下面我們來看整個過程圖
sentinel1和sentinel4同時向sentinel2發送信息，讓選自己
sentinel2很尷尬，都是好哥們，它會根據接收的先後順序去選擇
其他哨兵也同樣投票
最終sentinel1以絕對的優勢勝出，當選皇帝
最後sentinel1成功當選處置人選。
然後開始處置
服務器列表中挑選備選master
不在線的（OUT）
響應慢的（OUT）
與原master斷開時間久的（OUT）
優先原則
優先級
offset(優先級一樣，看偏移量)
runid(如果偏移量一樣，則論資排)
發送指令（sentinel）
向新的master發送slaveof no one
向其他slave發送slaveof新masterIP端口
總結：
- 監控
同步信息
- 通知
保持聯通
- 故障轉移
發現問題
競選負責人
優選新master
新master上任，其他slave切換master，原master作爲slave故障恢復後連接