下面我們就開始正式進入哨兵集群的搭建：

1、主從複製節點規劃->搭建一主兩從三哨兵

容器名稱 容器IP地址 映射埠號 服務運行模式
Redis-master 172.60.0.2 6382 -> 6379 Master
Redis-slave3 172.60.0.3 6383 -> 6379 Slave3
Redis-slave4 172.60.0.4 6384 -> 6379 Slave4
Redis-sentinel1 172.60.0.6 22536 -> 26379 Sentinel1
Redis-sentinel2 172.60.0.7 22537 -> 26379 Sentinel2
Redis-sentinel3 172.60.0.8 22538 -> 26379 Sentinel3

為了保證實踐的可行性和熟悉部分命令的使用，在執行本篇章的內容時，請注意以下情況：

1、請將前面篇章搭建的容器都刪除掉，然後重新構建容器，若不知如何刪除請自行查閱第五節篇章的命令。

2、當然你可以不刪，但是容器的IP和POST請自行變更就不要跟我上面部署的節點一樣了。

3、也可以對上一節篇章的容器進行適量改正，都可以。

4、構建容器的命令這裡也不啰嗦了，不知道的請查閱第三節篇章。

2、必須了解哨兵節點的幾個核心配置

sentinel monitor redis-master IP POST NUM

• sentinel monitor：配置命令
• redis-master：被監控的主節點名稱
• IP：被監控的主節點的IP地址
• POST：被監控的主節點的埠號
• NUM：監控並反饋多少個從節點redis-slave發現主節點有問題。

實例講解：sentinel monitor masterTop 192.168.0.1 6380 2。當有兩個從節點Slave發現並認為主節點名稱為masterTop ip地址是192.169.0.1 埠為6380的Master有問題，且ping不可達，就會執行故障轉移命令，而這種不可達是客觀存在的的判定方式，當NUM值越小那麼達到下線的條件就會越寬鬆，【比如若果這裡設置為1，當任意一個從節點發現有不可達的情況存在時就會發生轉移，這就不符合常理，前面的篇章有說過有可能是網路原因或者是本身的slave有問題就直接判定主有問題是不符合我們項目部署的，就想投票系統，投票多者的代表團才有最終的決議權】反之NUM值越大就會越嚴格，一般的建議是設置哨兵節點Sentinel總數的一半加1公式 NUM = sentinelTotal/2+1

注意：NUM 參數不能大於sentinel,為什麼不能大於，一旦設置大於了，哨兵集群將變成毫無意義。

sentinel down-after-millseconds redis-master ms

• ms：這裡是超時時間單位是毫秒。

講解：假如這裡設置10000 就是說明當ping不可達超過10000毫秒時就判定測試主節點已存在問題。當實例超過該時間沒有返回PING，或者直接返回錯誤， 那麼 Sentinel 將這個實例標記為主觀下線（subjectively down，簡稱 SDOWN ）。只有一個 Sentinel進程將實例標記為主觀下線並不一定會引起實例的自動故障遷移： 只有在足夠數量的 Sentinel 都將一個實例標記為主觀下線之後，實例才會被標記為客觀下線（objectively down， 簡稱 ODOWN ）， 這時自動故障遷移才會執行

sentinel parallel-syncs masterTop NUM

NUM：每次向主節點master發起的複製動作的從節點的個數。

講解：當哨兵節點Sentinel的集合對主節Master故障達成一致時，Sentinel領導者節點會發起故障轉移操作，並選取某個從節點Slave為新的主節點new Master，old Master變更為Slave，此時就會發生從節點向新的主節點發起複制的動作，那麼parallel-syncs配合NUM就能產生一個關鍵性的作用，用來限制每次的故障轉移後，每次向新的主節點發起複制操作的從節點的個數，並相對指出哨兵Sentinel是「並行複製」還是「串列複製」，當NUM設置為1時，表示每次發起複制的從節點只能有一個，就是「串列複製」的特性；當設置多個時，表示每次發起複制請求的從節點有多個明顯就是「並行複製」的主要特性，由此可見當NUM為1時非常能夠減輕Master的壓力。我們來畫個圖，讓大家更好地去理解下：

sentinel auth-pass <master-name> <password>

講解：如果 Sentinel 監控的主節點配置了密碼，sentinel auth-pass 配置通過添加主節點的密碼，防止 Sentinel 節點對主節點無法監控。就相對於握手協議，這個應該不難理解吧。

sentinel failover-timeout mymaster ms

ms：表示故障轉移的時間單位毫秒

講解：如果在該時間（ms）內未能完成failover操作，則認為該failover失敗。

3、哨兵節點的命令

• SENTINEL masters 顯示被監控的所有master以及它們的狀態.
• SENTINEL master <master name> 顯示指定master的信息和狀態；
• SENTINEL slaves <master name> 顯示指定master的所有slave以及它們的狀態；
• SENTINEL get-master-addr-by-name <master name> 返回指定master的ip和埠，如果正在進行failover或者failover已經完成，將會顯示被提升為master的slave的ip和埠。
• SENTINEL failover <master name> 強制sentinel執行failover，並且不需要得到其他sentinel的同意。但是failover後會將最新的配置發送給其他sentinel。
• 修改配置：
• sentinel monitor test 127.0.0.1 6379 2 添加新的監聽
• SENTINEL REMOVE test 放棄對某個master監聽
• SENTINEL set failover-timeout mymaster 180000 設置配置選項

4、構建哨兵集群

• 先構建好我們的容器：

• 分別進入兩個從節點配置主從關係，然後在我們的主節點可以看到兩個從節點已經連接到主節點的信息

• 從圖中我們可以很清楚地看到三台哨兵節點【容器】redis-sentinel1、redis-sentinel2、redis-sentinel3，接下面我們分別進入到這三台容器里：

[root@f6a00c943fc3 config]# vi /etc/redis-sentinel.conf
配置信息和之前一樣 修改bind 為0.0.0.0並打開protected-mode no
在第69行分別給三個哨兵節點配置主節點信息，如下圖：

• 然後分別啟動三個哨兵容器

[root@f6a00c943fc3 config]# redis-sentinel /etc/redis-sentinel.conf &

• 好了，哨兵節點我們部署完了，是不是很簡單呢？接下來，我們看看日誌檢測下看看是否已經配置成功：

在任何一個哨兵節點下：
[root@f6a00c943fc3 config]# vi /var/log/redis/sentinel.log

• 由此可見我們的哨兵集群順利搭建成功，下面我們就開始測試下哨兵集群的機制，我們先把我們現在的主節點172.60.0.2手動讓他停止kill掉，再看看會有什麼奇蹟發生：執行以下命令

查看下主節點6379埠號網路信息：
[root@8865433de980 config]# netstat -apn|grep 6379

• 我們可以看到進程的陣列，現在我們kill掉【您們在執行的時候這裡會跟我不一樣，我這是25，你們可能是26、27等】

當我們再次執行查看埠號網路信息的命令時：

告訴我們需要等待結果，哨兵節點開始協商討論重新選舉一個從節點為新的主節點了。我們再看下日誌結果：

• 看到奇蹟了沒我們的IP為172.60.0.4被選舉成了主節點，而我們的舊主節點172.60.0.2變成了從節點，那我們進入新任的主節點裡查看下信息

這裡就擁有了一個新的從節點172.60.0.3

• 那麼我們現在把舊主節點重啟下再看看我們的新的主節點redis-slave4會有什麼變化:

而此時的從節點正在進行複製動作，offset的偏移量還沒有和redis-slave3一致有一定的差距。

好了，今天就到這了，我也要洗洗睡了??，很高興為大家準備這些。我們下節的篇章就為大家講講哨兵節點的實現原理。感謝大家的支持，要想第一時間發現新文章，請關注我和我的專欄，同時歡迎大家點評並討論，謝謝，我們下個篇章繼續「開河」。

推薦閱讀：