Redis高可用集羣-哨兵模式（Redis-Sentinel）搭建配置教程【Windows環境】

Redis哨兵模式，用現在流行的話可以說就是一個“哨兵機器人”，給“哨兵機器人”進行相應的配置之後，這個”機器人”可以7*24小時工作，它能能夠自動幫助你做一些事情，如監控，提醒，自動處理故障等。

Redis-sentinel簡介
Redis-sentinel是Redis的作者antirez，因爲Redis集羣的被各大公司使用，每個公司要寫自己的集羣管理工具，於是antirez花了幾個星期寫出了Redis-sentinel。

Redis 的 Sentinel 系統用於管理多個 Redis 服務器（instance），Redis 的 Sentinel 爲Redis提供了高可用性。使用哨兵模式創建一個可以不用人爲干預而應對各種故障的Redis部署。

該系統執行以下三個任務：
http://rc.haian.gov.cn/company/company-show.php?id=1588232
http://rc.haian.gov.cn/company/company-show.php?id=1588233
http://rc.haian.gov.cn/company/company-show.php?id=1588234
http://rc.haian.gov.cn/company/company-show.php?id=1588235
http://rc.haian.gov.cn/company/company-show.php?id=1588236

監控（Monitoring）：Sentinel會不斷地檢查你的主服務器和從服務器是否允許正常。
提醒（Notification）：當被監控的某個Redis服務器出現問題時，Sentinel可以通過API向管理員或者其他應用程序發送通知。
自動故障遷移（Automatic failover）: （1）當一個主服務器不能正常工作時，Sentinel會開始一次自動故障遷移操作，他會將失效主服務器的其中一個從服務器升級爲新的主服務器，並讓失效主服務器的其他從服務器改爲複製新的主服務器；
（2）客戶端試圖連接失敗的主服務器時，集羣也會向客服端返回新主服務器的地址，是的集羣可以使用新主服務器代替失效服務器。
　
sentinel的分佈式特性
Redis Sentinel 是一個分佈式系統， 你可以在一個架構中運行多個 Sentinel 進程（progress）， 這些進程使用流言協議（gossip protocols)來接收關於主服務器是否下線的信息， 並使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從服務器作爲新的主服務器。

單個sentinel進程來監控redis集羣是不可靠的，當sentinel進程宕掉後(sentinel本身也有單點問題，single-point-of-failure)整個集羣系統將無法按照預期的方式運行。所以有必要將sentinel集羣，這樣有幾個好處：

有一些sentinel進程宕掉了，依然可以進行redis集羣的主備切換；

如果只有一個sentinel進程，如果這個進程運行出錯，或者是網絡堵塞，那麼將無法實現redis集羣的主備切換（單點問題）;

如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關於redis集羣中的信息

一個健壯的部署至少需要三個哨兵實例。

三個哨兵實例應該放置在客戶使用獨立方式確認故障的計算機或虛擬機中。例如不同的物理機或不同可用區域的虛擬機。【本次講解是一個機器上進行搭建，和多級是一個道理】

Redis-sentinel搭建
環境
Windows10
Redis-x64-3.2.100

本次搭建說明：
master：127.0.0.1:6379 【初始化master】

slave：127.0.0.1:6380 127.0.0.1:6381

sentinel：127.0.0.1:26379 127.0.0.1:26380 127.0.0.1:26381
1
2
3
4
5
6
7
8
9
10
11
安裝和基本配置
因爲之前已經介紹過Redis集羣的主從配置，裏面有安裝和基本配置，所以這裏不做介紹，不懂的請查看：Redis集羣主從複製（一主兩從）搭建配置教程【Windows環境】

Sentinel配置
根據安裝和基本配置，已經有了主從配置 ，對應文件夾Redis6379~Redis6381。然後在每個文件夾下面新增 一個名爲 sentinel.conf 的文件。配置內容如下：

這個是Redis6379配置內容，其他文件同理新增然後改一下端口即可，26380，和 26381。

#當前Sentinel服務運行的端口
port 26379

哨兵監聽的主服務器

sentinel monitor mymaster 127.0.0.1 6379 2

3s內mymaster無響應，則認爲mymaster宕機了

sentinel down-after-milliseconds mymaster 3000
#如果10秒後,mysater仍沒啓動過來，則啓動failover
sentinel failover-timeout mymaster 10000

執行故障轉移時， 最多有1個從服務器同時對新的主服務器進行同步

sentinel parallel-syncs mymaster 1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
配置文件只需要配置master的信息就好啦，不用配置slave的信息，因爲slave能夠被自動檢測到(master節點中有關於slave的消息)。

爲了更清楚每一行配置的含義，對每個選項的含義進行簡單介紹：

sentinel monitor [master-group-name] [ip] [port] [quorum]

master-group-name：master名稱（可以自定義）
ip port : IP地址和端口號
quorun：票數，Sentinel需要協商同意master是否可到達的數量。
第一行配置指示 Sentinel 去監視一個名爲 mymaster 的主服務器， 這個主服務器的 IP 地址爲 127.0.0.1 ， 端口號爲 6379 ， 而將這個主服務器判斷爲失效至少需要 2 個 Sentinel 同意 （只要同意 Sentinel 的數量不達標，自動故障遷移就不會執行）。
票數在本文中：redis集羣中有3個sentinel實例，其中master掛掉啦，這裏設置票數爲2，表示有2個sentinel認爲master掛掉啦，才能被認爲是正真的掛掉啦。

sentinel <選項的名字> <主服務器的名字> <選項的值>

down-after-milliseconds 選項指定了 Sentinel 認爲服務器已經斷線所需的毫秒數。
如果服務器在給定的毫秒數之內， 沒有返回 Sentinel 發送的 PING 命令的回覆， 或者返回一個錯誤， 那麼 Sentinel 將這個服務器標記爲主觀下線（subjectively down，簡稱 SDOWN ）。
不過只有一個 Sentinel 將服務器標記爲主觀下線並不一定會引起服務器的自動故障遷移： 只有在足夠數量的 Sentinel 都將一個服務器標記爲主觀下線之後， 服務器纔會被標記爲客觀下線（objectively down， 簡稱 ODOWN ）， 這時自動故障遷移纔會執行。
將服務器標記爲客觀下線所需的 Sentinel 數量由對主服務器的配置決定。

• parallel-syncs 選項指定了在執行故障轉移時， 最多可以有多少個從服務器同時對新的主服務器進行同步， 這個數字越小， 完成故障轉移所需的時間就越長。

5.其他配置
新增Redis啓動腳本：startRedisServer.bat

@echo off
redis-server.exe redis.windows.confbr/>@pause
1
2
3
4
新增Redis-Sentinel啓動腳本：startRedisSentinel.bat

@echo off
redis-server.exe sentinel.conf --sentinel br/>@pause
1
2
3
4
在配置啓動startrRedis6379.cmd,其他同理！

@echo off
cd Redis6379
startRedisServer.bat
1
2
3
4
在配置啓動startrRedisSentinel26379.cmd，其他同理！

@echo off
cd Redis6379
startRedisSentinel.bat
at
1
2
3
4
5
配置完如圖：

啓動Sentinel實例
哨兵啓動命令 redis-server.exe sentinel.conf –sentinel

第一步：點擊startRedis.cmd ，啓動Redis集羣 第二步：點擊startRedisSentinel.cmd ，啓動哨兵實例 查看Sentinel啓動日誌，看到“` 生成哨兵ID（Sentinel ID），並自動識別主服務器和從服務器！
[114252] 03 Mar 13:32:57.896 # Sentinel ID is 89f521b40a803495472c0457b0396473c4bfb100
[114252] 03 Mar 13:32:57.896 # +monitor master mymaster 127.0.0.1 6379 quorum 2
[114252] 03 Mar 13:32:57.909 +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:32:57.917 +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
1
2
3
4
5
查看主服務器6379（Master）信息：
F:\nosql_learn\Redis-Sentinel\Redis6379>redis-cli -p 6379
127.0.0.1:6379> info replication

Replication

role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=54148,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=54148,lag=1
master_repl_offset:54414
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:54413
127.0.0.1:6379>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
查看主服務器6380（Slave）信息：
127.0.0.1:6380> info replication

Replication

role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:80531
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6380>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Redis-Sentinel高可用場景演示
場景1：主服務器master宕機
當主服務器master宕機，那麼Sentinel會通過選舉（算法）機制，從Salve中選出一個作爲新Master。 大概原理是當選出一個Slave要作爲Master的時候，會發送命令slaveofno one來取消選中的這個slave，使其成爲Master。哨兵會發送給其他從服務器Slave配置選中的這個爲新主服務器Master，並刪除監聽列表中出現故障的Master服務器。 (1)關閉掉 6379主服務器
127.0.0.1:6379> shutdown
not connected>

1
2
3
4
(2)查看觀察選舉新的master的過程和顯示了failover的過程，整個日誌信息還是比較完整的。最後選舉了6381爲主服務器！
[114252] 03 Mar 13:32:59.945 +sentinel sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:33:00.018 +sentinel sentinel 7fc21e38de0408ccaa06111e44638e2693794e08 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.223 # +sdown master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.300 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2
[114252] 03 Mar 13:53:19.300 # +new-epoch 1
[114252] 03 Mar 13:53:19.300 # +try-failover master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.306 # +vote-for-leader 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.319 # 7fc21e38de0408ccaa06111e44638e2693794e08 voted for 89f521b40a803495472c0457b0396473c4bfb100 1
[114252] 03 Mar 13:53:19.369 # +elected-leader master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.370 # +failover-state-select-slave master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.428 +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:19.530 +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.327 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.328 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:20.398 +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.390 +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +failover-end master mymaster 127.0.0.1 6379
[114252] 03 Mar 13:53:21.445 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
[114252] 03 Mar 13:53:21.447 +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:21.449 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:23.193 # +sdown sentinel 926e67646440b200ee41bb224bacf9e0314e3b32 127.0.0.1 26379 @ mymaster 127.0.0.1 6381
[114252] 03 Mar 13:53:24.451 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
(3)查看6381服務器信息,角色爲主，從服務器6380！
127.0.0.1:6381> info replication

Replication

role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=33358,lag=1
master_repl_offset:33505
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33504
127.0.0.1:6381>
1
2
3
4
5
6
7
8
9
10
11
12
場景2：之前故障的6379 master重新啓動
（1）啓動6379服務，發現6379成爲6381的從服務器！
F:\nosql_learn\Redis-Sentinel\Redis6379>redis-server.exe redis.windows.conf

[116640] 03 Mar 13:59:25.753 The server is now ready to accept connections on port 6379
[116640] 03 Mar 13:59:48.315 SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=2 addr=127.0.0.1:61677 fd=7 name=sentinel-7fc21e38-cmd age=10 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec')
[116640] 03 Mar 13:59:48.326 # CONFIG REWRITE executed with success.
[116640] 03 Mar 13:59:48.826 Connecting to MASTER 127.0.0.1:6381
[116640] 03 Mar 13:59:48.851 MASTER <-> SLAVE sync started
1
2
3
4
5
6
7
（2）查看6381服務器狀態信息：原來的master自動切換成slave，不會自動恢復成master。
127.0.0.1:6381> info replication

Replication

role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=73183,lag=0
slave1:ip=127.0.0.1,port=6379,state=online,offset=73183,lag=0
master_repl_offset:73183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:73182
127.0.0.1:6381>
1
2
3
4
5
6
7
8
9
10
11
12
13
場景3：從服務器Slave宕機和重啓
（1）關閉6380從服務器：
127.0.0.1:6380> shutdown
not connected>
1
2
3
（2）Sentinel日誌：
[113488] 03 Mar 14:06:50.143 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
1
2
（3）查看住服務器6381狀態信息：
127.0.0.1:6381> info replication

Replication

role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=111361,lag=1
master_repl_offset:111361
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:111360
127.0.0.1:6381>
1
2
3
4
5
6
7
8
9
10
11
12
（4）啓動從服務器6380
Connecting to MASTER 127.0.0.1:6381
1
（5）查看住服務器6381狀態信息：6380又回來了！
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6379,state=online,offset=141232,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=141232,lag=1
master_repl_offset:141232
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:141231
127.0.0.1:6381>
1
2
3
4
5
6
7
8
9
10
11
Redis-sentinel相關知識
主觀下線和客觀下線
每個 Sentinel 都需要定期執行的任務
自動發現 Sentinel 和從服務器
….
可以參考 Redis 的 Sentinel 文檔