由于工作時間的問題，今天才給大家分享我們的第七篇章，讓大家久等了....

上一篇章，我們了解到了redis主從復制的哨兵集群，簡單的一句話就是，“時時對主節點進行監控，一旦發現多個從節點都無法正常ping通主節點，哨兵節點就會自我協商推薦某個
從節點進階為新任盟主成為主節點Master，并同時把舊的主節點變更為從節點。”舉個三者之間的協議對話。

舊主節點：Fxxxk，我才是盟主，

哨兵節點：勝者為王，既然你自甘墮落，只能罷了你！

新任主節點：風水輪流轉，誰讓你不爭氣呢，怪我嘍？

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

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的壓力。我們來畫個圖，讓大家更好地去理解下：

parallel-syncs=3的表示每次三個從節點發起復制動作：并行復制

parallel-syncs=1的表示每次只有一個從節點發起復制動作：串行復制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一致有一定的差距。

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

總結

以上是生活随笔為你收集整理的netcore部署到docker 实现excel生成_Docker部署Redis集群----第七节（docker-redis-sentinel集群实现篇）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。