關於redis的哨兵

 　　以前有說到redis的主從分離架構以實現提升redis的高水平擴展能力，可是單單是這樣的主從架構是存在着一些問題的：

　　master（主）節點掛了會發生什麼？

　　master掛了，那麼master下的從節點一樣的處於不可用狀態了。即master那一片都掛了。由於slave（從）節點不能再接收到新的數據

　　slave節點掛了會怎麼樣？

　　若是是一個slave節點掛了，那麼還有其餘的slave節點對外提供服務，不至於全部的請求都發向後臺的數據庫中致使數據庫壓力忽然增大。

　　redis進程掛掉了會怎麼樣？

　　這就比較厲害了，進程掛掉了redis就沒用了，有的時候redis進程掛掉了，而你有剛好沒有給redis設置數據的持久化，redis可能會丟失較多的數據，除此外這臺機器的這個進程的redis確定也不能對外提供服務了。帶來的問題就和前面兩個同樣的了，若是是master的進程，同master節點掛了；若是是slave的進程，同slave節點掛了。

　　解決辦法：

　　哨兵，對zookeeper有了解的話會很容易理解這個機制，在這裏簡要的說明一下哨兵的工做。這裏以zookeeper來作哨兵模式的講解。首先zookeeper是一個分佈式鎖的服務，根據CPA理論，在分佈式系統中，系統只能達到CAP理論中的兩個要求，沒法知足所有三個。

　　這個不難理解。C：數據的一致性，P：數據的分區容錯性，A:數據的可用性。zookeeper實現的主要是CAP中的一致性（C）和分區容錯性（P）不過你就算姑且認爲zookeeper主要實現的是一致性（C）也ok，zookeeper在A方面的確不算強調的地方。同時因爲zookeeper的非高可用性，zookeeper被認爲不適合做爲服務發現的系統。固然並不是說zookeeper不能用，只是他的可用性不算好而已。zookeeper實現其強一致性還依靠於其樹狀的文件式的結構，拿到一個節點建立一個文件等於拿到一個鎖，並拒絕其餘人獲取這個鎖。其餘想獲取這個鎖的人須要等待並排隊，同時監聽（watcher 機制）當前鎖是否被釋放，若是監聽的鎖釋放且當前等待以前沒有其餘的等待者，那麼獲取這個鎖。並執行須要的操做。

　　回到哨兵機制：哨兵是爲了保證主從架構的可用性。在須要監聽的進程的機器下開一個哨兵進程，哨兵進程會監視主進程，如master節點是否掛掉了之類的，而且記錄其信息，根據信息判斷監視的節點是否真的掛了，掛掉了的話就要從新選舉master節點，以求保證高可用性。那麼這和zookeeper又有什麼關係呢？

　　　　前面有提到，由於zookeeper的強一致性，zookeeper提供的信息一般都是準確的，且是當前狀態最正確的（分佈式系統中），那麼哨兵將它監視的節點的內容存放到zookeeper的一個節點下就能保證其餘節點一直沒法在這個節點下寫內容，只有當哨兵主動刪除這個節點時其餘節點纔有機會向這個節點寫內容。何時哨兵會主動刪除節點？當哨兵以爲它監聽的進程處於掛掉狀態的時候，。

　　　　接下來講一下redis中的哨兵：

redis集羣架構中的哨兵主要功能：

1. 集羣監控，負責監控redis master和slave進程是否正常工做
2. 消息通知，若是某個redis實例有故障，那麼哨兵負責發送消息做爲報警通知給管理員
3. 故障轉移，若是master node掛掉了，會自動轉移到slave node上
4. 配置中心，若是故障轉移發生了，通知client客戶端新的master地址

 

關於哨兵   再講

（1）哨兵至少須要3個實例，來保證本身的健壯性
（2）哨兵 + redis主從的部署架構，是不會保證數據零丟失的，只能保證redis集羣的高可用性
（3）對於哨兵 + redis主從這種複雜的部署架構，儘可能在測試環境和生產環境，都進行充足的測試和演練

爲何redis哨兵集羣只有2個節點沒法正常工做？

哨兵集羣必須部署2個以上節點

若是哨兵集羣僅僅部署了個2個哨兵實例，quorum=1

+----+ 　　  +----+
| M1 |---------| R1 |
| S1 |　　    | S2 |
+----+　　   +----+

Configuration: quorum = 1

master宕機，s1和s2中只要有1個哨兵認爲master宕機就能夠還行切換，同時s1和s2中會選舉出一個哨兵來執行故障轉移

同時這個時候，須要majority，也就是大多數哨兵都是運行的，2個哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2個哨兵都運行着，就能夠容許執行故障轉移

可是若是整個M1和S1運行的機器宕機了，那麼哨兵只有1個了，此時就沒有majority來容許執行故障轉移，雖然另一臺機器還有一個R1，可是故障轉移不會執行

3節點哨兵集羣

　　   +----+
　　　| M1 |
　　　| S1 |
　　　+----+
　　　　|
+----+     |　 +----+
| R2 |----+----| R3 |
| S2 |    　　 | S3 |
+----+ 　　   +----+

Configuration: quorum = 2，majority

若是M1所在機器宕機了，那麼三個哨兵還剩下2個，S2和S3能夠一致認爲master宕機，而後選舉出一個來執行故障轉移

同時3個哨兵的majority是2，因此還剩下的2個哨兵運行着，就能夠容許執行故障轉移。

 

好了如今關於redis的主從節點切換的哨兵差很少講了一些。可是哨兵帶來的問題仍是很煩人的。。

　　因爲哨兵集羣一般監視的是分佈式系統的集羣，哨兵天然也是分佈式，那就會帶來CAP的問題：

　這裏指的CAP是哨兵與其餘系統之間的CAP還有切換前的master與切換後的master數據不一致，並不是哨兵之間的CAP。