1 哨兵的作用
哨兵是redis集群架構中非常重要的乙個元件，主要功能如下：
集群監控：負責監控redis master和sl**e程序是否正常工作
訊息通知：如果某個redis例項有故障，那麼哨兵負責傳送訊息作為報警通知給管理員
故障轉移：如果master node掛掉了，會自動轉移到sl**e node上
配置中心：如果故障轉移發生了，通知client客戶端新的master位址
2 哨兵的核心知識
故障轉移時，判斷乙個master node是宕機了，需要大部分的哨兵都同意才行，涉及到了分布式選舉的問題哨兵至少需要3個例項，來保證自己的健壯性哨兵 + redis主從的部署架構，是不會保證資料零丟失的，只能保證redis集群的高可用性3 sdown和odown
sdown和odown兩種失敗狀態sdown是主觀宕機，就乙個哨兵如果自己覺得乙個master宕機了，那麼就是主觀宕機odown是客觀宕機，如果quorum數量的哨兵都覺得乙個master宕機了，那麼就是客觀宕機sdown達成的條件：如果乙個哨兵ping乙個master，超過了is-master-down-after-milliseconds指定的毫秒數之後，就主觀認為master宕機odown達成的條件：如果乙個哨兵在指定時間內，收到了quorum指定數量的其他哨兵也認為那個master是sdown了，那麼就認為是odown了，客觀認為master宕機4 quorum和majority
quorum：確認odown的最少的哨兵數量majority：授權進行主從切換的最少的哨兵數量每次乙個哨兵要做主備切換，首先需要quorum數量的哨兵認為odown，然後選舉出乙個哨兵來做切換，這個哨兵還得得到majority哨兵的授權，才能正式執行切換如果quorum < majority，比如5個哨兵，majority就是3，quorum設定為2，那麼就3個哨兵授權就可以執行切換，但是如果quorum >= majority，那麼必須quorum數量的哨兵都授權，比如5個哨兵，quorum是5，那麼必須5個哨兵都同意授權，才能執行切換5 為什麼哨兵至少3個節點
哨兵集群必須部署2個以上節點。如果哨兵集群僅僅部署了個2個哨兵例項，那麼它的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），如果其中乙個哨兵宕機了，就無法滿足majority>=2這個條件，那麼在master發生故障的時候也就無法進行主從切換。
6 腦裂以及redis資料丟失
主備切換的過程，可能會導致資料丟失 （1）非同步複製導致的資料丟失 因為master -> sl**e的複製是非同步的，所以可能有部分資料還沒複製到sl**e，master就宕機了，此時這些部分資料就丟失了 （2）腦裂導致的資料丟失 腦裂，也就是說，某個master所在機器突然脫離了正常的網路，跟其他sl**e機器不能連線，但是實際上master還執行著 此時哨兵可能就會認為master宕機了，然後開啟選舉，將其他sl**e切換成了master，這個時候，集群裡就會有兩個master，也就是所謂的腦裂。 此時雖然某個sl**e被切換成了master，但是可能client還沒來得及切換到新的master，還繼續寫向舊master的資料可能也丟失了，因此舊master再次恢復的時候，會被作為乙個sl**e掛到新的master上去，自己的資料會清空，重新從新的master複製資料
7 如何盡可能減少資料丟失
下面兩個配置可以減少非同步複製和腦裂導致的資料丟失：
min-sl**es-to-write 1min-sl**es-max-lag 1012解釋：要求至少有1個sl**e，資料複製和同步的延遲不能超過10秒，如果說一旦所有的sl**e，資料複製和同步的延遲都超過了10秒鐘，那麼這個時候，master就不會再接收任何請求了 （1）減少非同步複製的資料丟失 有了min-sl**es-max-lag這個配置，就可以確保說，一旦sl**e複製資料和ack延時太長，就認為可能master宕機後損失的資料太多了，那麼就拒絕寫請求，這樣可以把master宕機時由於部分資料未同步到sl**e導致的資料丟失降低的可控範圍內 （2）減少腦裂的資料丟失 如果乙個master出現了腦裂，跟其他sl**e丟了連線，那麼上面兩個配置可以確保說，如果不能繼續給指定數量的sl**e傳送資料，而且sl**e超過10秒沒有給自己ack訊息，那麼就直接拒絕客戶端的寫請求，這樣腦裂後的舊master就不會接受client的新資料，也就避免了資料丟失 上面的配置就確保了，如果跟任何乙個sl**e丟了連線，在10秒後發現沒有sl**e給自己ack，那麼就拒絕新的寫請求 因此在腦裂場景下，最多就丟失10秒的資料
8 哨兵集群的自動發現機制
哨兵互相之間的發現，是通過redis的pub/sub系統實現的，每個哨兵都會往sentinel:hello這個channel裡傳送乙個訊息，這時候所有其他哨兵都可以消費到這個訊息，並感知到其他的哨兵的存在 每隔兩秒鐘，每個哨兵都會往自己監控的某個master+sl**es對應的sentinel:hello channel裡傳送乙個訊息，內容是自己的host、ip和runid還有對這個master的監控配置 每個哨兵也會去監聽自己監控的每個master+sl**es對應的sentinel:hello channel，然後去感知到同樣在監聽這個master+sl**es的其他哨兵的存在 每個哨兵還會跟其他哨兵交換對master的監控配置，互相進行監控配置的同步
9 sl**e配置的自動糾正
哨兵會負責自動糾正sl**e的一些配置，比如sl**e如果要成為潛在的master候選人，哨兵會確保sl**e在複製現有master的資料; 如果sl**e連線到了乙個錯誤的master上，比如故障轉移之後，那麼哨兵會確保它們連線到正確的master上
10 master選舉演算法
如果乙個master被認為odown了，而且majority哨兵都允許了主備切換，那麼某個哨兵就會執行主備切換操作，此時首先要選舉乙個sl**e來。 選舉的時候會考慮sl**e的一些資訊： （1）跟master斷開連線的時長 （2）sl**e優先順序 （3）複製offset （4）run id 如果乙個sl**e跟master斷開連線已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那麼sl**e就被認為不適合選舉為master，計算公式如下：
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_sdown_state1接下來會對sl**e進行排序 （1）按照sl**e優先順序進行排序，sl**e priority越低，優先順序就越高 （2）如果sl**e priority相同，那麼看replica offset，哪個sl**e複製了越多的資料，offset越靠後，優先順序就越高 （3）如果上面兩個條件都相同，那麼選擇乙個run id比較小的那個sl**e
11 configuration epoch
哨兵會對一套redis master+sl**e進行監控，有相應的監控的配置 執行切換的那個哨兵，會從要切換到的新master（salve->master）那裡得到乙個configuration epoch，這就是乙個version號，每次切換的version號都必須是唯一的 如果第乙個選舉出的哨兵切換失敗了，那麼其他哨兵，會等待failover-timeout時間，然後接替繼續執行切換，此時會重新獲取乙個新的configuration epoch，作為新的version號
12 configuraiton傳播
哨兵完成切換之後，會在自己本地更新生成最新的master配置，然後同步給其他的哨兵，就是通過之前說的pub/sub訊息機制 這裡之前的version號就很重要了，因為各種訊息都是通過乙個channel去發布和監聽的，所以乙個哨兵完成一次新的切換之後，新的master配置是跟著新的version號的 其他的哨兵都是根據版本號的大小來更新自己的master配置的
Redis 配置哨兵
關閉兩端 linux 的防火牆 service iptables stop關閉兩端 redis.conf 的受保護機制 protected mode no在從redis 中配置 replicaof 主 redis ip 埠拷貝解壓目錄下的配置檔案 sentinel.conf root admin r...
Redis 配置哨兵
關閉兩端 linux 的防火牆 service iptables stop關閉兩端 redis.conf 的受保護機制 protected mode no在從redis 中配置 replicaof 主 redis ip 埠拷貝解壓目錄下的配置檔案 sentinel.conf root admin r...
redis哨兵機制
為了解決redis主從複製模式致命缺點，當主節點宕機，影響整個系統執行，引入哨兵機制sentinel。sentinel哨兵主要解決以下問題 哨兵配置如下 哨兵工作原理 哨兵是乙個特殊的redis伺服器，不同的是命令以及不會持久化，啟動時，根據配置檔案中master主節點ip和埠，建立兩個連線，一為命...