為什么redis哨兵集群只有2個節(jié)點無法正常工作？

由于redis的響應(yīng)速度快，每秒支持的并發(fā)極高(號稱10萬)，現(xiàn)在redis越來越流行了
redis支持的存儲有: string， hash(map)，list, set, sortset 同時可以使用redis的setnx 來實現(xiàn)分布式鎖
首先談?wù)剅edis的哨兵模式：

哨兵支持對主從的監(jiān)控，并且當(dāng)主節(jié)點掛機(jī)之后，可以啟動從節(jié)點升級為主節(jié)點繼續(xù)提供服務(wù)
同時哨兵也支持對客戶端提供發(fā)現(xiàn)服務(wù)，客戶端通過連接哨兵從而獲取主節(jié)點的信息，如果主節(jié)點掛機(jī)，在升級從節(jié)點為主節(jié)點之后，客戶端通過哨兵可以連接上新的主節(jié)點
主節(jié)點和從節(jié)點之間通過同步寫命令來保持?jǐn)?shù)據(jù)一致（在啟動的時候會立刻先同步主節(jié)點的快照，保存主節(jié)點的信息）
判斷節(jié)點是否宕機(jī)并且需要重啟需要幾個哨兵協(xié)同判斷，當(dāng)一定數(shù)量的哨兵(可配置) 認(rèn)為主節(jié)點宕機(jī)才會去升級從節(jié)點
接下來談?wù)剅edis的集群模式

redis集群從多主多從共同支撐，至少需要三個主節(jié)點才能啟動集群
每個集群包含 16384個槽 ，每一個主（從節(jié)點負(fù)責(zé)同步主節(jié)點的數(shù)據(jù)）負(fù)責(zé)存儲其中的某一個槽，redis 通過對key的hash 確定存儲在哪一個槽上面，
當(dāng)需要加入新的節(jié)點或者刪除節(jié)點的時候 ，redis 會去維護(hù)不同主節(jié)點上面的槽，從而重新分配槽的所屬
為什么redis哨兵集群只有2個節(jié)點無法正常工作？

哨兵集群必須部署2個以上節(jié)點
如果哨兵集群僅僅部署了個2個哨兵實例，quorum=1

Configuration: quorum = 1
master宕機(jī)，s1和s2中只要有1個哨兵認(rèn)為master宕機(jī)就可以還行切換，同時s1和s2中會選舉出一個哨兵來執(zhí)行故障轉(zhuǎn)移
同時這個時候，需要majority，也就是大多數(shù)哨兵都是運(yùn)行的，2個哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2個哨兵都運(yùn)行著，就可以允許執(zhí)行故障轉(zhuǎn)移
但是如果整個M1和S1運(yùn)行的機(jī)器宕機(jī)了，那么哨兵只有1個了，此時就沒有majority來允許執(zhí)行故障轉(zhuǎn)移，雖然另外一臺機(jī)器還有一個R1，但是故障轉(zhuǎn)移不會執(zhí)行
經(jīng)典的3節(jié)點哨兵集群

Configuration: quorum = 2，majority
如果M1所在機(jī)器宕機(jī)了，那么三個哨兵還剩下2個，S2和S3可以一致認(rèn)為master宕機(jī)，然后選舉出一個來執(zhí)行故障轉(zhuǎn)移
同時3個哨兵的majority是2，所以還剩下的2個哨兵運(yùn)行著，就可以允許執(zhí)行故障轉(zhuǎn)移