在講哨兵模式之前，我們有必要先來介紹一下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入職機制的缺點：

有延遲，從機越多，延遲多嚴重