Redis服務之高可用組件sentinel

　　前文咱們瞭解了redis的經常使用數據類型相關命令的使用和說明，回顧請參考http://www.javashuo.com/article/p-qvvmnuco-nq.html；今天咱們來聊一下redis的高可用組件sentinel；首先來回顧下redis的主從同步，主從同步最主要的做用是讓master的數據在其餘服務器上實時存在副本，起到了備份的效果；對於redis的讀寫來講，主從架構可以讓讀的請求分散到多個從服務器上，從而下降了單臺redis讀請求的io壓力，同時也提升了redis讀請求的併發能力；一般爲了數據的一致性，從服務器一旦成爲某一臺redis的slave，那麼從服務器上以前有的數據會被清空，而後把master發送過來的數據應用到內存，從而實現和master數據一致；除此以外slave一般會是隻讀屬性，也就說slave端只能執行讀操做，寫操做會被拒絕，因此寫請求始終是由master來完成；那麼問題來了，對於這種主從複製架構的環境中，若是master宕機了，master宕機意味着整個系統將不可以寫數據到redis,很顯然這種狀況咱們應該及時解決；怎麼解決呢？有沒有這樣的一組件幫咱們對master作實時的監控，一旦發現master宕機就提高一個slave當選新的master，若是原master還有其餘slave，將其餘slave都從屬於新的master；除此以外它還應該讓系統在發生切換master時觸發報警通知，讓管理員儘快把壞掉的master修復上線；對，sentinel就有咱們上述的這些功能，它可以監控主從同步集羣中的master節點，在master發生宕機後可以自動故障轉移，將提高一臺slave做爲新的master，而後通知管理員；

　　Sentinel是一個分佈式系統，咱們能夠在一個架構中運行多個sentinel，這些sentinel進程使用流言協議（gossipprotocols）來接收關於 Master是否下線的信息，並使用投票協議(Agreement Protocols)來決定是否執行自動故障遷移,以及選擇哪一個 Slave 做爲新的 Master。每一個sentinel進程會向其餘sentinel進程、master、slave定時發送消息，以確保對方是否」活」着，若是發現對方在指定配置時間(可配置的)內未獲得迴應，則暫時認爲對方已掉線，也就是所謂的」主觀認爲宕機」 ，英文名稱：Subjective Down，簡稱 SDOWN。有主觀宕機，確定就有客觀宕機。當多個sentinel進程中多數的sentinel進程在對 Master 作出 SDOWN 的判斷，而且經過 SENTINEL is-master-down-by-addr 命令互相交流以後，得出的 Master Server 下線判斷，這種方式就是「客觀宕機」，英文名稱是：Objectively Down， 簡稱 ODOWN。經過必定的 vote 算法，從剩下的 slave 從服務器節點中，選一臺提高爲 Master 服務器節點，而後自動修改相關配置，並開啓故障轉移（failover）。

　　配置使用sentinel

　　環境說明

角色	ip地址	端口
master	192.168.0.41	6379
slave01	192.168.0.42	6379
slave02	192.168.0.43	6379
sentinel01	192.168.0.41	26379
sentinel02	192.168.0.42	26379
sentinel03	192.168.0.43	26379

 

 

 

 

 

 

 

 

 

　　架構圖

　　提示：從上面的架構圖能夠知道，首先咱們必需要有一個主從架構的集羣，而後在部署sentinel 來對主從同步集羣作監控；

　　redis主從複製集羣搭建

　　一、在192.168.0.41/42/43上安裝redis，可使用yum安裝，也可使用編譯安裝，redis安裝請參考http://www.javashuo.com/article/p-ckvacwaq-kp.html；

　　二、配置192.168.0.41/42/43上的redis監聽在非本機127.0.0.1上並配置42/43上的redis從屬於192.168.0.41

　　master

　　slave01

　　slave02

　　提示：redis支持在線修改配置，保存配置到配置文件；SLAVEOF 指令用於指定redismaster的ip地址和端口，表示把該redis配置成對應master的slave角色；CONFIG REWRITE是把咱們的配置保存到配置文件；

　　在master上查看是否有兩個從節點鏈接到master

　　驗證：在master上寫數據，看看是否可以及時同步到兩個slave上？

　　提示：能夠看到在主庫上寫數據，從庫上可以及時的同步主庫上的數據；到此redis的主從集羣就搭建完畢了；

　　配置sentinel，讓其監控master

　　提示：三個sentinel的配置都是同樣的，這裏須要明確指定監控主從同步集羣的master的ip地址和端口，以及有效法定票數，有效法定票數指的是至少有多少個sentinel主觀認爲master down了，而後才觸發選舉新master操做；一般在這種流言協議中，通常都是大於集羣半數，若是是3臺sentinel，至少要2臺主觀認爲master宕機，纔開始觸發選舉新master；若是是5臺，那至少要3臺；若是master配置的有認證密碼，咱們還須要在sentinel中指定認證密碼；

　　sentinel配置文件說明

　　bind：該指令和redis配置文件中的bind是一樣的用法，用於指定sentinel的監聽地址；默認不指定，監聽本機全部可用地址；

　　protected-mode：指定是否開啓保護模式；

　　port：用於指定sentinel的監聽端口；默認是26379

　　daemonize：用於指定sentinel是否運行爲守護進程，yes表示運行爲後臺守護進程；no表示不運行爲守護進程，直接在前臺運行；

　　pidfile：指定pid文件路徑；

　　logfile：指定日誌文件路徑；

　　dir：指定sentinel的工做路徑；

　　sentinel monitor <master-name> <ip> <redis-port> <quorum>：用於指定監控master節點的ip地址和端口以及有效法定票數；其中<master-name>是給監控的master一個名稱，能夠隨便寫，起標識的做用；<quorum>表示sentinel集羣的quorum機制，即至少有quorum個sentinel節點同時斷定主節點故障時，才認爲其真的故障；

　　sentinel auth-pass <master-name> <password>：指定master認證密碼；一般都須要設置密碼，而且master的密碼和slave的密碼應該是同樣；

　　sentinel down-after-milliseconds <master-name> <milliseconds>：配置監控到指定的集羣的主節點異常狀態持續多久方纔將標記爲「故障」；

　　sentinel parallel-syncs <master-name> <numslaves>：指在failover過程當中，可以被sentinel並行配置的從節點的數量；

　　sentinel failover-timeout <master-name> <milliseconds>：sentinel必須在此指定的時長內完成故障轉移操做，不然，將視爲故障轉移操做失敗；

　　sentinel notification-script <master-name> <script-path>：通知腳本，此腳本被自動傳遞多個參數；

　　瞭解了sentinel的配置文件，接下咱們把3臺sentinel都啓動起來

　　master

　　slave01

　　slave02

　　提示：從上面的信息能夠看到3個sentinel都監空master的ip地址和端口，他們3個的配置文件都是同樣的；

　　查看sentinel日誌

　　提示：從上面的日誌信息能夠了解到sentinel監控的master是192.168.0.41：6379；而且有兩個slave分別是192.168.0.42：6379和192.168.0.43：6379；

　　查看sentinel狀態

　　提示：它提示咱們開啓了保護模式；

　　關閉保護模式

　　重啓sentinel，再次查看sentinel狀態

[root@master ~]# systemctl restart redis-sentinel.service 
[root@master ~]# ss -tnl
State      Recv-Q Send-Q        Local Address:Port                       Peer Address:Port              
LISTEN     0      511                       *:26379                                 *:*                  
LISTEN     0      511                       *:6379                                  *:*                  
LISTEN     0      128                       *:22                                    *:*                  
LISTEN     0      100               127.0.0.1:25                                    *:*                  
LISTEN     0      511                      :::26379                                :::*                  
LISTEN     0      128                      :::22                                   :::*                  
LISTEN     0      100                     ::1:25                                   :::*                  
[root@master ~]# redis-cli -h 192.168.0.41 -p 26379       
192.168.0.41:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.0.41:6379,slaves=2,sentinels=3
192.168.0.41:26379> info clients
# Clients
connected_clients:3
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
192.168.0.41:26379> CLIENT LIST
id=2 addr=192.168.0.42:59048 fd=14 name=sentinel-f60b324b-cmd age=38 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=3 addr=192.168.0.43:37480 fd=15 name=sentinel-eada229c-cmd age=38 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=publish
id=4 addr=192.168.0.41:36706 fd=16 name= age=32 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
192.168.0.41:26379> 

　　提示：從上面的狀態信息能夠看到當前咱們sentinel監控的master是出於正常ok狀態，有兩個slave和3個sentinel；對於192.168.0.41：26379目前有3個客戶端鏈接，二個是sentinel，一個本機；到此3臺sentinel搭建啓動完成；

　　驗證：把master宕機，看看sentinel是否將在兩個從節點選舉一個爲新master？是否將另一個slave從新指向新master？

　　在slave02上查看主從同步信息

　　提示：第一次查看只是告訴咱們master宕機了，第二次查看就告訴咱們當前節點爲master，而且擁有一個slave節點；

　　在192.168.0.43上查看主從信息，看看是否指向新的master？

　　提示：在slave02上看主從同步信息，能夠看到slave02已經從屬新master了；

　　查看故障轉移時 sentinel日誌

　　提示：從上面的日誌信息能夠了解到，在從sdown到odown後，就會觸發vote算法開始選舉leader；而後將原master降級爲slave，而後將選舉出來的leader原salve屬性去除（slaveof no one）;而後提示新master，而後將剩下的slave從新配置新master爲主；最後是切換master，開始新的監控；

　　查看故障 轉移後的 s redis 配置文件

　　提示：故障轉移後 redis.conf 中的 slaveof 行的 master IP 會被修改，sentinel.conf 中的 sentinel monitor IP 會被修改。同時在sentinel配置文件的末尾還會有添加known-slave和known-sentinel等信息；

　　修復舊master 讓其從新上線

　　提示：把原master啓動後，它自動就成爲了新主的slave；這主要是由於sentinel在故障轉移時把其配置文件中的slaveof 修改爲新的master地址了；

　　在新master上查看主從同步信息

　　提示：在沒有恢復原master時，在新master上查看主從同步信息，只能看到一個salve，啓動原master後，在看就有兩個slave是在線；