redis-sentinel高可用配置（2）
一：說明
前面我們已經配置了redis的主從配置（鏈接），這種主從架構有一個問題，當主master出現了故障了，怎么切換到從服務器上呢？
第一種：手動切換， 這種肯定會造成比較長一段時間的用戶不能訪問redis了，那有沒有更好的辦法呢？
第二種：redis官方的 redis-sentinel 哨兵高可用，可以自動切換到從服務器，把從服務器提升為主服務器，繼續進行服務。
sentinel的作用
Redis的sentinel系統可以管理多個Redis實例，該系統主要有以下三個任務：
1) 監控 ： sentinel會不斷的檢查你的主服務器和從服務器是否正常運行
2) 提醒：當被監控的某個Redis服務器出問題時，sentinel可以通過api向管理員或者其他應用程序發通知
3）自動轉移故障：當一個主服務器不能正常工作時，sentinel會開始一次自動故障遷移操作，它會將失效主服務器的其中一個從服務器升級為主服務器，并讓失效主服務器的其他從服務器改為復制新的主服務器；
當客戶端試圖連接失效的主服務器時，集群也會向客戶端返回新的主服務器地址，使得集群可以用新主服務器代替失效的服務器。
關于sentinel
sentinel可以在redis編譯后的src文檔中找到，它是一個命名為redis-sentinel的程序
二：sentinel的配置
配置文件的格式：
sentinel 選項的名字 主Redis實例的名字 選項的值
Redis 源碼中包含了一個名為 sentinel.conf 的文件， 這個文件是一個帶有詳細注釋的 Sentinel 配置文件示例。
運行一個 Sentinel 配置示例如下：
?
配置文件解釋：
第一行配置指示 Sentinel 去監視一個名為 mymaster 的主redis實例， 這個主實例的 IP 地址為本機地址127.0.0.1 ， 端口號為 6379 ， 而將這個主服務器判斷為失效至少需要 2 個 Sentinel 進程的同意，只要同意 Sentinel 的數量不達標，自動failover就不會執行。
同時，一個Sentinel都需要獲得系統中大多數Sentinel進程的支持， 才能發起一次自動故障遷移， 并預留一個給定的配置紀元 （configuration Epoch ，一個配置紀元就是一個新主服務器配置的版本號）。
換句話說， 在只有少數（minority） Sentinel 進程正常運作的情況下， Sentinel 是不能執行自動故障遷移的。
各個選項的功能：
down-after-milliseconds
該選項指定了 Sentinel 認為Redis實例已經失效所需的毫秒數。
當實例超過該時間沒有返回PING，或者直接返回錯誤， 那么 Sentinel 將這個實例標記為主觀下線（subjectively down，簡稱 SDOWN ）。
只有一個 Sentinel進程將實例標記為主觀下線并不一定會引起實例的自動故障遷移： 只有在足夠數量的 Sentinel 都將一個實例標記為主觀下線之后，實例才會被標記為客觀下線（objectively down， 簡稱 ODOWN ）， 這時自動故障遷移才會執行。
parallel-syncs
該選項指定了在執行故障轉移時， 最多可以有多少個從Redis實例在同步新的主實例， 在從Redis實例較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長。
盡管復制過程的絕大部分步驟都不會阻塞從實例， 但從redis實例在載入主實例發來的 RDB 文件時， 仍然會造成從實例在一段時間內不能處理命令請求： 如果全部從實例一起對新的主實例進行同步， 那么就可能會造成所有從Redis實例在短時間內全部不可用的情況出現。
所以從實例被設置為允許使用過期數據集（參見對 redis.conf 文件中對 slave-serve-stale-data 選項），可以緩解所有從實例都在同一時間向新的主實例發送同步請求的負擔。你可以通過將這個值設為 1 來保證每次只有一個從Redis實例處于不能處理命令請求的同步狀態。
failover-timeout
如果在該時間（ms）內未能完成failover操作，則認為該failover失敗。
notification-script
指定sentinel檢測到該監控的redis實例指向的實例異常時，調用的報警腳本。該配置項可選，但是很常用。
三：主觀下線和客觀下線
前面說過， Redis 的 Sentinel 中關于下線（down）有兩個不同的概念：
主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷。
客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務器下線判斷。 （一個 Sentinel 可以通過向另一個 Sentinel 發送 SENTINEL is-master-down-by-addr 命令來詢問對方是否認為給定的服務器已下線。）
如果一個服務器沒有在 master-down-after-milliseconds 選項所指定的時間內， 對向它發送 PING 命令的 Sentinel 返回一個有效回復（valid reply）， 那么 Sentinel 就會將這個服務器標記為主觀下線。
?
服務器對 PING 命令的有效回復可以是以下三種回復的其中一種：
返回 +PONG 。
返回 -LOADING 錯誤。
返回 -MASTERDOWN 錯誤。
如果服務器返回除以上三種回復之外的其他回復， 又或者在指定時間內沒有回復 PING 命令， 那么 Sentinel 認為服務器返回的回復無效（non-valid）
注意， 一個服務器必須在 master-down-after-milliseconds 毫秒內， 一直返回無效回復才會被 Sentinel 標記為主觀下線。
舉個例子， 如果 master-down-after-milliseconds 選項的值為 30000 毫秒（30 秒）， 那么只要服務器能在每 29 秒之內返回至少一次有效回復， 這個服務器就仍然會被認為是處于正常狀態的。
四：每個 Sentinel 都需要定期執行的任務
- 每個 Sentinel 以每秒鐘一次的頻率向它所知的主服務器、從服務器以及其他 Sentinel 實例發送一個 PING 命令。
- 如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那么這個實例會被 Sentinel 標記為主觀下線。 一個有效回復可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
- 如果一個主服務器被標記為主觀下線， 那么正在監視這個主服務器的所有 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態。
- 如果一個主服務器被標記為主觀下線， 并且有足夠數量的 Sentinel （至少要達到配置文件指定的數量）在指定的時間范圍內同意這一判斷， 那么這個主服務器被標記為客觀下線。
- 在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主服務器和從服務器發送 INFO 命令。 當一個主服務器被 Sentinel 標記為客觀下線時， Sentinel 向下線主服務器的所有從服務器發送 INFO 命令的頻率會從 10 秒一次改為每秒一次。
- 當沒有足夠數量的 Sentinel 同意主服務器已經下線， 主服務器的客觀下線狀態就會被移除。 當主服務器重新向 Sentinel 的 PING命令返回有效回復時， 主服務器的主管下線狀態就會被移除。
五：自動發現 Sentinel 和從服務器
一個 Sentinel 可以與其他多個 Sentinel 進行連接， 各個 Sentinel 之間可以互相檢查對方的可用性， 并進行信息交換。
你無須為運行的每個 Sentinel 分別設置其他 Sentinel 的地址， 因為 Sentinel 可以通過發布與訂閱功能來自動發現正在監視相同主服務器的其他 Sentinel ， 這一功能是通過向頻道 __sentinel__:hello 發送信息來實現的。
與此類似， 你也不必手動列出主服務器屬下的所有從服務器， 因為 Sentinel 可以通過詢問主服務器來獲得所有從服務器的信息。
- 每個 Sentinel 會以每兩秒一次的頻率， 通過發布與訂閱功能， 向被它監視的所有主服務器和從服務器的 __sentinel__:hello 頻道發送一條信息， 信息中包含了 Sentinel 的 IP 地址、端口號和運行 ID （runid）
- 每個 Sentinel 都訂閱了被它監視的所有主服務器和從服務器的 __sentinel__:hello 頻道， 查找之前未出現過的 sentinel （looking for unknown sentinels）。 當一個 Sentinel 發現一個新的 Sentinel 時， 它會將新的 Sentinel 添加到一個列表中， 這個列表保存了 Sentinel 已知的， 監視同一個主服務器的所有其他 Sentinel
- Sentinel 發送的信息中還包括完整的主服務器當前配置（configuration）。 如果一個 Sentinel 包含的主服務器配置比另一個 Sentinel 發送的配置要舊， 那么這個 Sentinel 會立即升級到新配置上。
- 在將一個新 Sentinel 添加到監視主服務器的列表上面之前， Sentinel 會先檢查列表中是否已經包含了和要添加的 Sentinel 擁有相同運行 ID 或者相同地址（包括 IP 地址和端口號）的 Sentinel ， 如果是的話， Sentinel 會先移除列表中已有的那些擁有相同運行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel?
六：Sentinel API
在默認情況下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服務器使用的是 6379 ）。
Sentinel 接受 Redis 協議格式的命令請求， 所以你可以使用 redis-cli 或者任何其他 Redis 客戶端來與 Sentinel 進行通訊。
有兩種方式可以和 Sentinel 進行通訊：
- 第一種方法是通過直接發送命令來查詢被監視 Redis 服務器的當前狀態， 以及 Sentinel 所知道的關于其他 Sentinel 的信息， 諸如此類。
- 另一種方法是使用發布與訂閱功能， 通過接收 Sentinel 發送的通知： 當執行故障轉移操作， 或者某個被監視的服務器被判斷為主觀下線或者客觀下線時， Sentinel 就會發送相應的信息
Sentinel 命令
以下列出的是 Sentinel 接受的命令：
- PING ：返回 PONG 。
- SENTINEL masters ：列出所有被監視的主服務器，以及這些主服務器的當前狀態。
- SENTINEL slaves <master name> ：列出給定主服務器的所有從服務器，以及這些從服務器的當前狀態。
- SENTINEL get-master-addr-by-name <master name> ： 返回給定名字的主服務器的 IP 地址和端口號。 如果這個主服務器正在執行故障轉移操作， 或者針對這個主服務器的故障轉移操作已經完成， 那么這個命令返回新的主服務器的 IP 地址和端口號。
- SENTINEL reset <pattern> ： 重置所有名字和給定模式 pattern 相匹配的主服務器。 pattern 參數是一個 Glob 風格的模式。 重置操作清除主服務器目前的所有狀態， 包括正在執行中的故障轉移， 并移除目前已經發現和關聯的， 主服務器的所有從服務器和 Sentinel 。
- SENTINEL failover <master name> ： 當主服務器失效時， 在不詢問其他 Sentinel 意見的情況下， 強制開始一次自動故障遷移 （不過發起故障轉移的 Sentinel 會向其他 Sentinel 發送一個新的配置，其他 Sentinel 會根據這個配置進行相應的更新）
七：配置sentinel實例
1：前面文章的主從配置
鏈接 http://www.cnblogs.com/starlion/p/9071003.html 接著繼續配置redis sentinel
a）修改前面的主從配置文件
這3個配置文件在ip為 192.168.0.109 虛擬機上
首先： 把 master slave1 slave2 目錄下面的redis.conf配置文件里的 bind 修改為 0.0.0.0
其次：把slave1 slave2目錄下的redis.conf配文件里的 slaveof 修改為 slaveof 192.168.0.109 1000
然后重啟3個redis實例
b) 配置sentinel文件
我們把sentinel配置在 192.168.0.110 的虛擬機上
打開redis的安裝目錄，在目錄下就有一個sentinel.conf的配置文件，這個就是配置sentinel的魔板文件
我們配置3個sentinel文件，文件名分別為 sentinel1.conf sentinel2.conf sentinel3.conf
# vi /user/local/redis/sentinel1.conf
?
# vi /user/local/redis/sentinel2.conf
protected-mode no logfile "/var/log/sentinel.log" port 26380 sentinel monitor mymaster 192.168.0.109 1000 2 sentinel down-after-milliseconds mymaster 15000 sentinel config-epoch mymaster 1?
# vi /user/local/redis/sentinel3.conf
protected-mode no logfile "/var/log/sentinel.log" port 26381 sentinel monitor mymaster 192.168.0.109 1000 2 sentinel down-after-milliseconds mymaster 15000 sentinel config-epoch mymaster 1?
c) 啟動sentinel
nohup ./bin/redis-sentinel ./sentinel1.conf & nohup ./bin/redis-sentinel ./sentinel2.conf & nohup ./bin/redis-sentinel ./sentinel3.conf &?
2. 連接sentinel
在默認情況下，Sentinel 使用TCP端口26379（普通 Redis 服務器使用的是 6379）。Sentinel 接受 Redis 協議格式的命令請求， 所以你可以使用 redis-cli 或者任何其他 Redis 客戶端來與 Sentinel 進行通訊。
有兩種方式可以和 Sentinel 進行通訊：
第一種方法是通過直接發送命令來查詢被監視 Redis 服務器的當前狀態， 以及進行主動轉移等操作。這些命令包括：
a). PING ：返回 PONG
?
b). SENTINEL masters ：列出所有被監視的主Redis服務實例，以及這些主服務實例的當前狀態。SENTINEL slaves ：列出給定主服務實例的所有從實例，以及這些從實例的當前狀態
127.0.0.1:26379> sentinel masters 1) 1) "name" 2) "mymaster" 3) "ip" 4) "192.168.0.109" 5) "port" 6) "1000" 7) "runid" 8) "2ee92794d04b4dcb25f684a9aecd356eb346d80d" 9) "flags" 10) "master" ... ...... 35) "quorum" 36) "2" 37) "failover-timeout" 38) "180000" 39) "parallel-syncs" 40) "1" 41) "notification-script"127.0.0.1:26379> sentinel slaves mymaster 1) 1) "name" 2) "192.168.0.109:2000" 3) "ip" 4) "192.168.0.109" 5) "port" 6) "2000" 7) "runid" 8) "4d590175947961683240d7077a4d34e657f072c0" ... ... 36) "3000" 37) "slave-priority" 38) "100" 39) "slave-repl-offset" 40) "10696170" 2) 1) "name" 2) "192.168.0.109:3000" 3) "ip" 4) "192.168.0.109" 5) "port" 6) "3000" 7) "runid" ... ... 33) "master-host" 34) "192.168.0.109" 35) "master-port" 36) "3000" 37) "slave-priority" 38) "100" 39) "slave-repl-offset" 40) "10696170"?
c). SENTINEL get-master-addr-by-name ： 返回給定名字的主實例的 IP 地址和端口號。 如果這個主實例正在執行故障轉移操作， 或者針對這個主實例的故障轉移操作已經完成， 那么這個命令返回新的主服務器的 IP 地址和端口號。
127.0.0.1:26379> sentinel get-master-addr-by-name mymaster 1) "192.168.0.109" 2) "1000"?
d). SENTINEL failover ：進行一次主動的failover。即在不詢問其他 Sentinel 意見的情況下， 強制開始一次自動故障遷移 。發起故障轉移的 Sentinel 會向其他 Sentinel 發送一個新的配置，其他 Sentinel 會根據這個配置進行相應的更新
127.0.0.1:26379> sentinel failover mymaster OK?
e). SENTINEL reset ： 重置所有名字和給定模式 pattern 相匹配的主服務器。 pattern 參數是一個 Glob 風格的模式。 重置操作清除該sentinel的所保存的所有狀態信息，并進行一次重新的發現過程。
127.0.0.1:26379> sentinel reset myredis (integer) 1?
第二種方法是使用發布與訂閱功能， 通過接收 Sentinel 發送的通知： 當執行故障轉移操作， 或者某個被監視的實例被判斷為主觀下線或者客觀下線時， Sentinel 就會發送相應的信息。
一個頻道能夠接收和這個頻道的名字相同的事件。 比如說， 名為 +sdown 的頻道就可以接收所有實例進入主觀下線（SDOWN）狀態的事件。
通過執行 PSUBSCRIBE * 命令可以接收所有事件信息。例如：
?
被動failover測試
查看當前的主redis ip和端口是多少
?
master ip 192.168.0.109
port 2000
關掉 2000 的這個redis實例，等 down-after-millisenonds后，查看/var/log/sentinel.log 日志，
?
看日志，這時候master 是 3000，登錄上 3000 服務器，看看端口3000的redis實例是不是master
[root@localhost]# ./redis-cli -p 3000 -h 192.168.0.109 192.168.0.109:3000> info replication # Replication role:master connected_slaves:1 slave0:ip=192.168.0.109,port=1000,state=online,offset=78092,lag=0?
我們啟動redis實例，它會自動作為slave連上 3000 這臺master redis實例
查看日志： vi /usr/local/redis/slave1/redis.log， 是否連上master，可以看到下面的日志連上了
?
連上2000的客戶端，看看情況：
[root@localhost]# ./redis-cli -p 2000 -h 192.168.0.109 192.168.0.109:2000> info replication # Replication role:slave master_host:192.168.0.109 master_port:30002000這臺實例是一個slave，說明成功連上了
測試成功。最后需要注意的是，sentinel集群自身也需要多數機制，也就是2個sentinel進程時，掛掉一個另一個就不可用了。
?
參考：
http://debugo.com/redis-sentinel/
https://redis.io/topics/sentinel
http://redisdoc.com/topic/sentinel.html
?
轉載于:https://www.cnblogs.com/jiujuan/p/9091337.html
總結
以上是生活随笔為你收集整理的redis-sentinel高可用配置（2）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： qq没有微粒贷怎么办
- 下一篇： 开通小黑鱼黄金会员能下款吗