- 哨兵機制
(1) 哨兵機制的核心功能
① 核心功能是主節點的自動故障轉移
(2) 下圖是一張典型的哨兵集羣監控的邏輯圖
(3) 哨兵實現了什麼功能？
① 監控：哨兵會不斷的檢查主節點和從節點是否運行正常
② 自動故障轉移：當主節點不能正常運行時，哨兵會開始自動故障轉移操作，它會將失效主節點的其中一個節點升級爲新的主節點，並讓其他節點改爲複製新的主節點
③ 配置提供者：客戶端在初始化時，通過連接哨兵來獲得當前Redis服務的主節點地址
④ 通知：哨兵可以將故障轉移的結果發送給客戶端
- 哨兵集羣的組建
(1) 哨兵集羣是如何組建的？
① 哨兵實例之間可以相互發現，要歸公於Redis提供的pub/sub機制，也就是發佈/訂閱機制
② 實例
1) 在主從集羣中，主庫上有一個名爲__sentinel__:hello的頻道，不同哨兵就是通過它來相互發現，實現相互通信的，在下圖中，哨兵1把自己的IP(172.16.19.3)和端口(26579)發佈到__sentinel__:hello頻道上，哨兵2和哨兵3訂閱了該頻道。此時，哨兵2和哨兵3就可以從這個頻道上直接獲取哨兵1的IP地址和端口號。然後哨兵2和3就可以和哨兵1建立網絡連接
2) 圖示
- 哨兵監控Redis庫
(1) 哨兵監控什麼？如何監控？
① 這是由哨兵向主庫發送INFO命令來完成的。如下圖，哨兵2給主庫發送INFO命令，主庫接收到這個命令後，就會把從庫列表返回給哨兵。接着哨兵就可以根據從庫列表中的連接信息，和每個從庫建立連接，並在這個連接上持續地對從庫進行監控，哨兵1和哨兵3可以通過相同的方式和從庫建立連接
② 圖示
- 主庫下線的判斷
(1) 哨兵如何判斷主庫已經下線了？
① 分類
1) 主觀下線：任何一個哨兵都可以監控探測，並作出Redis節點下線的判斷
2) 客觀下線：由哨兵集羣共同決定Redis是否下線
② 實例
1) 當某個哨兵(如下圖中的哨兵2)判斷主庫”主庫下線”後，就會給其他哨兵發送is-master-down-by-addr命令。接着其他哨兵根據自己和主庫的連接情況，做出Y或者N的響應，Y相當於贊成票，N相當於反對票
2) 圖示
如果贊成票數(上面是2)是大於等於哨兵配置文件中的quorum配置項(比如這裏如果是quorum=2),則可以判定主庫客觀下線了
- 哨兵集羣的選取(重點)
(1) 爲什麼必然會出現選舉/共識機制？
① 爲了避免哨兵的單點情況的發生，所以需要一個哨兵的分佈式集羣。作爲分佈式集羣，必然涉及到共識問題(即選舉問題)；同時故障的轉移和通知都只需要一個主的哨兵節點就可以了
(2) 哨兵的選舉機制是什麼樣的？
① 描述
1) 哨兵的選舉機制就是一個Raft選舉算法：選舉的票數大於等於num(sentinel)/2+1時，將成爲領導者，如果沒有超過繼續選舉
(3) 任何一個想要成爲Leader的哨兵，要滿足兩個條件
① 拿到半數以上的贊成票
② 拿到票數的同時還要大於等於哨兵配置文件中的quorum值
(4) 區分判定客觀下線和是否能夠主從切換(用到選舉機制)兩個概念
① Redis一主四從，五個哨兵，哨兵配置quorum=2,如果三個哨兵故障，哨兵能否判斷主庫”客觀下線”？能否自動切換?
1) 哨兵集羣可以判定主庫”主庫下線”。由於quorum=2,所以當一個哨兵判斷主庫”主管下線”後。詢問另外一個哨兵也會得到同樣的結果，2個哨兵都達到了quorum值，因此，哨兵集羣可以判定主庫爲”客觀下線”
2) 哨兵不能完成主從切換。哨兵標記主庫”客觀下線”後，在選舉哨兵領導者時，一個哨兵必須拿到超過多數的選票5/2+1=3.但是，目前只有兩個哨兵或者，所以無論如果達不到N/2+1的結果
- 新主庫的選出
(1) 主庫既然已經判定客觀下線了，那麼如果從剩餘的從庫中選擇一個新的主庫呢？
① 過濾掉不健康的(下線或斷線)，沒有回覆過哨兵響應的從節點
② 選擇slave-priority從優先級最高(redis.conf)的
③ 選擇複製偏移量最大，指複製最完整的從節點
④ 圖解
- 故障的轉移：新的主庫選擇出來後，就可以開始進行故障的轉移了
(1) 實例：假設一開始的圖：判斷主庫客觀下線了，同時選出了sentinel3是哨兵的leader）
(2) 故障轉移流程下
① 將slave-1脫離原從節點，升級爲主節點
② 將從節點slave-2指向新的主節點
③ 通知客戶端主節點已經更換
④ 將原主節點變爲從節點，指向新的主節點
(3) 轉移之後
