a: 在主從模式下, 如果從庫跪了, 客戶端可以繼續向其他從庫傳送請求, 進行相關的操作, 但是如果主庫跪了, 就無法向主庫中寫資料, 主庫中的資料也無法同步到從庫. 對於高可靠的集群來說, 肯定是不可取的. 因此需要有乙個角色來做如下相關的事情:
如下圖所示:
而上述這些事情就是哨兵來做的.
a: 小菜, 你問的問題越來越有水平了. 首先,哨兵要監聽主從庫的資訊需要通過監聽主從庫心跳來判斷, 一般都是ping操作. 想要監聽網路主從庫的心跳必須先要與主從庫建立網路連線.下面分別說明哨兵與其他端如何建立連線:
sentinel monitor除了哨兵例項，我們自己編寫的應用程式也可以通過 redis 進行訊息的發布和訂閱。所以，為了區分不同應用的訊息，redis 會以頻道的形式，對這些訊息進行分門別類的管理. 所謂的頻道，實際上就是訊息的類別。當訊息類別相同時，它們就屬於同乙個頻道。反之，就屬於不同的頻道。只有訂閱了同乙個頻道的應用，才能通過發布的訊息進行資訊交換。
在主從集群中，主庫上有乙個名為「sentinel:hello」的頻道，不同哨兵就是通過它來相互發現，實現互相通訊的。
具體如下圖:
具體的事件和頻道如下:
哨兵與其他端建立連線方式如下:
這裡會有乙個問題, 可能由於網路阻塞等原因, 傳送給主庫的 ping 命令沒有及時響應, 這樣有可能對主庫下線狀態誤判, 為了避免這種情況, redis通常判斷主庫是否下線有兩種狀態「主觀下線」和「客觀下線」;
主觀下線: 在哨兵集群中, 如果只有乙個哨兵判斷主庫已經下線則是判斷為主觀下線;
客觀下線: 如果有大多數的哨兵例項，都判斷主庫已經「主觀下線」了，主庫才會被標記為「客觀下線」;
這個判斷原則就是：少數服從多數。
如下圖所示:
簡單來說，「客觀下線」的標準就是，當有 n 個哨兵例項時，最好要有 n/2 + 1 個例項判斷主庫為「主觀下線」，才能最終判定主庫為「客觀下線」。這樣一來，就可以減少誤判的概率，也能避免誤判帶來的無謂的主從庫切換。（當然，有多少個例項做出「主觀下線」的判斷才可以，可以由 redis 管理員自行設定, 設定的引數為quorum）。
a: 選主的過程通常分為兩步: 篩選和選主;
篩選: 從庫的數量可能很多, 需要先按一定的條件進行篩選, 把不符合規範的從庫淘汰掉;
選主: 按一定的規則給剩下的主庫打分, 將得分最高的從庫選為新主庫.
具體如下圖:
篩選規則:
第一點很好理解, 下面主要說明第二點: 設想一下，如果在選主時，乙個從庫正常執行，我們把它選為新主庫開始使用了。可是，很快它的網路出了故障，此時，我們就得重新選主了。這顯然不是我們期望的結果。使用配置項down-after-milliseconds*10。其中，down-after-milliseconds是我們認定主從庫斷連的最大連線超時時間。如果在down-after-milliseconds毫秒內，主從節點都沒有通過網路聯絡上，我們就可以認為主從節點斷連了。如果發生斷連的次數超過了10次，就說明這個從庫的網路狀況不好，不適合作為新主庫。
選主規則:
選主過程:
然後，依次按照優先順序、複製進度、id 號大小再對剩餘的從庫進行打分，只要有得分最高的從庫出現，就把它選為新主庫。
a:通知。在執行通知任務時，哨兵會把新主庫的連線資訊發給其他從庫，讓它們執行replicaof命令，和新主庫建立連線，並進行資料複製。同時，哨兵會把新主庫的連線資訊通知給客戶端，讓它們把請求操作發到新主庫上。
a: 小菜, 現在發現對問題思考越來越深入了. 確實在選主的過程中有乙個帶頭大哥(主哨兵)在主持選主的工作. 首先需要了解一下如何選擇這個主哨兵的.
哨兵leader的兩個條件:
哨兵選注的過程:
任何乙個例項只要自身判斷主庫「主觀下線」後，就會給其他例項傳送 is-master-down-by-addr 命令。
其他例項會根據自己和主庫的連線情況，做出 y (同意為leader)或 n(不同意) 的響應，y 相當於贊成票，n 相當於反對票。(在同一輪投票中, 第一次投出的y, 包括自己投自己在內, 之後都是n)
這麼說可能還不太好理解，我再畫一張，展示一下 3 個哨兵、quorum 為 2 的選舉過程。
注意: 如果哨兵集群只有 2 個例項，此時，乙個哨兵要想成為 leader，必須獲得 2 票，而不是 1 票。所以，如果有個哨兵掛掉了，那麼，此時的集群是無法進行主從庫切換的。因此，通常我們至少會配置 3 個哨兵例項。這一點很重要，實際應用時可不能忽略了。
在解決乙個系統問題的時候，會引入乙個新機制，或者設計一層新功能，就像我們在這兩節課學習的內容：為了實現主從切換，我們引入了哨兵；為了避免單個哨兵故障後無法進行主從切換，以及為了減少誤判率，又引入了哨兵集群；哨兵集群又需要有一些機制來支撐它的正常執行。
支援哨兵集群的這些關鍵機制如下:
對於主從切換，當然不是哪個哨兵想執行就可以執行的，否則就亂套了。所以，這就需要哨兵集群在判斷了主庫「客觀下線」後，經過投票仲裁，選舉乙個 leader 出來，由它負責實際的主從切換，即由它來完成新主庫的選擇以及通知從庫與客戶端。
redis之哨兵集群（2）
前面提到過，如果乙個哨兵在執行過程中發生故障，那麼是不是還能進行主從庫切換 實際上一旦多個例項組成了哨兵集群，即使有哨兵例項出現故障掛掉了，其他哨兵還能繼續協作完成主從庫切換的工作，包括判定主庫是不是處於下線狀態，選擇新主庫，以及通知從庫和客戶端。配置哨兵所用到的資訊 sentinel monito...
Redis 哨兵集群
redis核心技術與實戰 08 哨兵掛了，還能監測主庫狀態，保證服務不間斷嗎？多個例項組成哨兵集群，即使乙個哨兵掛掉了，其他哨兵也可以繼續協作完成主從庫切換的工作，包括判定主庫是不是處於下線狀態，選擇新主庫，以及通知從庫和客戶端。在配置哨兵的資訊時，我們只需要用到下面的這個配置項，設定主庫的 ip ...
redis主從,哨兵集群
準備工作 本文用的linux為centos6.5,redis為5.0.9在兩台伺服器 redis安裝請看 redis版本 5.0.9 主 172.16.38.225 26379 sentinel 26380 主 172.16.38.226 26379 sentinel 26380 redis支援主從...