在講哨兵模式之前，我們有必要先來介紹一下redis另外兩種複製策略：
1. 上一篇文章講了關於一主二僕的結構，但是這種結構有一個明顯的弊端，那就是過於中心化，所有的請求都來自一個主機，主機的負擔太重，很正常的我們會想到，可不可以創建一種鏈式結構來解決這個問題呢？當然是可以的啦！再redis中通常情況下一個slaver會跟隨一個master，但是slaver也可以連接另外一個slaver，作爲另外那個slaver的master，當然他並不是真正意義上的master，只是相對而言是一個master，下圖所示：
依然是使用slaveof語句，只不過6381端口的redis目標是6380，所以，81的相對主機是80，80的相對主機是79，很簡單。
2. 反客爲主：顧名思義，他的意思就是說從機代替原來主機的位置變成了新的master，我現在恢復一主二僕的結構，然後將主機退出，按照上一篇講的內容可以知道主機斷開連接之後，他的從機會原地待命，，這個時候，如果主機遲遲不能恢復工作，那麼我們就必須尋求一種方法來是系統能夠繼續正常運行，理所當然的是從這些從機之中選擇一個成爲新的主機，然後將其餘的從機連接到這個新的主機上面，構成一個新的體系。
將從機變成主機使用到的命令式slaveof on one ，將其他從機連接到這個主機使用的命令依然是slaveof：
可以看到，新的體系已經構建完成，有一主一從兩個服務器。
需要注意的是，此時如果主機恢復工作，那麼他將再這個新體系之外，單獨的一個服務，本身是master，沒有任何slaver。
好了，下面我們要說說哨兵模式了，哨兵模式說白了就是將反客爲主的一些列動作自動化，他會在後臺有一個監控，監控當前的主機，巡邏主機下面的從機，如果某一時刻主機掛掉了，那麼他會通過一種投票的機制從從機之中選舉一臺作爲新的主機，並且，其餘的從機將會連接到這個新的主機上面。下面演示一下他的工作流程：
1. 首先，在/myredis下面新建一個sentinel.conf文件：touch sentinel.conf,在其中設置監控的主機以及投票策略，其格式爲：
sentinel monitor 主機名 主機ip 主機端口 票數n 票數多餘n的從機作爲主機
然後通過redis-sentinel命令執行這個文件，爲主機開啓哨兵：
可以看到這個就是類似於哨兵的日誌打印，每當哨兵有動作執行的時候都會打印到這裏，下面我們再一個master的結構下讓主機掛掉，來看看會發生什麼：
正常情況下，主機掛了之後，從機的角色依然是slaver，但是此時，有了哨兵之後，主機掛了，哨兵會投票選舉一個從機作爲新的master，可以看到，稍微等待幾秒鐘之後，81端口的從機成爲了新的主機，同時，80端口成爲了81端口的從機，我們來看看哨兵打印的日誌：
可以看到整個投票選舉的過程。
那麼現在，我再次啓動主機又會發生什麼呢？
啓動主機之後，可以看到（稍微等幾秒）81端口主機從一個連接數變成了兩個，沒錯，就是恢復了的舊主機變成了81端口的從機，如下是哨兵的日誌打印：
即：原來的主機恢復了以後，就會自動的轉爲從機跟隨新主機。
redis入職機制的缺點：
有延遲，從機越多，延遲多嚴重