Redis中sentinel集群的搭建和Jedis測試圖文教程[三]

Redis中sentinel集群的搭建和Jedis測試圖文教程[三]

　　在前兩篇Redis中sentinel集群的搭建和Jedis測試 圖文教程[一] 和Redis中sentinel集群的搭建和Jedis測試 圖文教程[二] 中分別簡述了Redis中sentinel集群的搭建和Java代碼的Jedis測試。
　　
　　這篇主要來簡單分析一下Redis-sentinel集群的原理，根據追蹤sentinel信息來完成Redis-sentinel集群測試中的詳細的原理分析。包括master-slave各個中的sentinel信息的分析，failover過程，master宕機後的leader選舉過程等等方面深層次詳細簡述了其各個原理。

一、Redis常見HA方案

　　HA(High Available，高可用性群集)機集群系統簡稱，是保證業務連續性的有效解決方案，一般有兩個或兩個以上的節點，且分為活動節點及備用節點。通常把正在執
行業務的稱為活動節點，而作為活動節點的一個備份的則稱為備用節點。當活動節點出現問題，導致正在運行的業務（任務）不能正常運行時，備用節點此時就會偵測到，並立即接續活動節點來執行業務。從而實現業務的不中斷或短暫中斷。From 百度百科.
　　Redis 一般以主/從方式部署（這裡討論的應用從實例主要用於備份，主實例提供讀寫）該方式要實現 HA 主要有如下幾種方案：
　　1）keepalived：通過 keepalived 的虛擬 IP，提供主從的統一訪問，在主出現問題時， 通過 keepalived 運行腳本將從提升為主，待主恢復後先同步後自動變為主，該方案的好處是主從切換後，應用程序不需要知道(因為訪問的虛擬 IP 不變)，壞處是引入 keepalived 增加部署復雜性，在有些情況下會導致數據丟失；
　　2） zookeeper： 通過 zookeeper 來監控主從實例， 維護最新有效的 IP， 應用通過 zookeeper取得 IP，對 Redis 進行訪問，該方案需要編寫大量的監控代碼；
　　3）sentinel：通過 Sentinel 監控主從實例，自動進行故障恢復，該方案有個缺陷：因為主從實例地址(IP&PORT)是不同的， 當故障發生進行主從切換後， 應用程序無法知道新地址，故 在 Jedis2.2.2 中 新 增 了 對 Sentinel 的 支 持 ， 應 用 通 過redis.clients.jedis.JedisSentinelPool.getResource()取得的Jedis實例會及時更新到新的主實例地址。
　　下面是該方案的部署邏輯圖。

二、Redis-sentinel配置與部署

　　詳情請見Redis中sentinel集群的搭建和Jedis測試 圖文教程[一]
　　由於 sentinel 服務器已經在 redis 服務器的環境中（redis-sentinel），我們這裡就直接使用它們（在生產環境中，sentinel 服務器和 redis-server 服務器一般是分離的，部署在不同的pc-server 上面，同時 sentinel 的個數和 redis-server 個數也沒聯系，下面為了方便學習使用將3 台 sentinel 服務都放到了一台 pc 上)。
　　注意： sentinel 配置文件只和默認的 master 有關系，和 slave 都沒有關系。我們上面的例子是用了 3 個 redis-server 和 3 個 redis-sentinel，其實 redis-sentinel的個數不一定要和 redis-sever 對應，1~n 個都可以。
　　首先要清楚，sentinel是一個獨立於redis之外的進程，不對外提供key/value服務。在redis的安裝目錄下名稱叫 redis-sentinel 。 主要用來監控redis-server進程，進行master/slave管理，如果你的redis沒有運行在master/slave模式下，不需要設置sentinel。

三、Redis-sentinel啟動和檢測

　　分別啟動 redis-server 和redis-sentinel。
　　
　　1）啟動 redis-0 時 redis-0 的 sentinel 控制台
　　
　　
　　2）啟動 redis-1 時 reids-1 的 sentinel 控制台
　　
　　
　　啟動 redis-1 時 reids-0 的 sentinel 控制台
　　
　　
　　3）啟動 redis-2 時 reids-2 的 sentinel 控制台
　　
　　
　　啟動 redis-2 時 reids-0 的 sentinel 控制台
　　
　　
　　啟動 redis-2 時 reids-1 的 sentinel 控制台
　　 <喎?http://www.Bkjia.com/kf/ware/vc/" target="_blank" class="keylink">vcD4KCjxwPqGhoaHNqLn9yc+1xL/Y1sbK5LP20MXPor/J0tS/tLP2o6zU2tLAtM7G9Lavt/7O8cqxo6y21NPDv9jWxsyoyuSz9sHLK3NlbnRpbmVsoaIrc2xhdmWhoi1zZG93biC1yNDFz6KjrMu1w/e497j2IHNlbnRpbmVsINauvOS9+NDQwcvNqNG2o6y2+MfS0rK84L/Ytb3ByyByZWRpcy1zZXJ2ZXIgtcTH6b/2oaMrc2VudGluZWwgse3KvtPQ0MK1xCBzZW50aW5lbCDKtcD9vNPI67W9vOC/2KGjzOHKvqO6yte0zrm5vaggc2VudGluZWwgu7e+s8qxo6yx2NDrytfPyMb0tq8gbWFzdGVyILv6xvehoyAgPGJyPgqhoaGhIDxicj4KoaGhoTSjqbLpv7TP4LnY0MXPoiAgPGJyPgqhoaGhyrnTwyAjIG5ldHN0YXQgLW50bHAg" grep redis 命令可以看到當前 redis 運行情況。
　　
　　
　　通過 redis-cli 查看 redis-server 的狀態

/usr/local/webserver/redis/redis-cli -h 127.0.0.1 -p 6379 -a abcd123457 info Replication

　　(上面的 -a 用來輸入密碼)
　　

說明：info 指令
　　該指令將會打印完整的服務信息，包括集群，我們只需要關注”Replication”部分（在上面的命令中，我們在 info 後面加上了 Replication 的限制，如果不加，這還會輸出 Server、Clients、Memory、Persistence、Stats、CPU 和 Keyspace 等信息），這部分信息將會告訴我們”當前 server 的角色”以及指向它的所有的 slave 信息。可以通過在任何一個 slave 上，使用”INFO”指令獲得當前 slave 所指向的 master 信息。下面是 slave1 的 Replication 信息。
　　　
　　
　　同時，該指令不僅可以幫助我們獲得集群的情況，當然 sentinel 組件也是使用”INFO”做同樣的事情。下面是 slave2 的 sentinel 信息。
　　　
　　
　　通過上面信息，可以清楚看到 redis 服務狀態和主從關系。　
　
　　5）failover 測試
　　當上述部署環境穩定後，我們直接關閉 redis-0，在等待”down-after-milliseconds”秒之後(30 秒)，redis-0/redis-1/redis-2 的 sentinel 窗口會立即打印”+sdown”、”+odown”、”+failover”、”+selected-slave”、 “+promoted-slave”、 “+slave-reconf”等等一系列指令， 這些指令標明當 master失效後，sentinel 組件進行 failover 的過程。
　　模擬 mater 宕機的情況。此時各 sentinel 控制台輸出如下信息。
　　
　　redis-0 上的 sentinel 信息.
　　　

　　redis-1 上的 sentinel 信息
　　
　　
　　redis-2 上的 sentinel 信息
　　

　　從上面三個窗口的信息可以看出， 當 master 宕機後， 三個 sentinel(哨兵)進行了對 master進行了故障轉移。

{從 redis-1 的 sentinel 控制台可以看出，進行了下面的操作。
a.+sdown mater mymaster 127.0.0.1 6379 (主觀認為 mater 失效)；
b.+odown mater mymaster 127.0.0.1 6379 #quorum 2/2（已經有兩個哨兵認為 master 主觀失效，則認為 mater 客觀失效）；
c.+new-epoch 1(准備進行新 mater 的選取)；
d.+try-failover master mymaster 127.0.0.1 6379（嘗試熱備份切換，master 讓出位置）；
e.+vote-for-leader 1eb0f03b7a7815c3c5506b0fa041ad8d6ca9db90 1（投票選舉 Leader）；
f.127.0.0.1:16379 voted for 1eb0f03b7a7815c3c5506b0fa041ad8d6ca9db90 1（投票選舉Leader）；
g.127.0.0.1:36379 voted for 1eb0f03b7a7815c3c5506b0fa041ad8d6ca9db90 1（投票選舉Leader）；
h.+elected-leader master mymaster 127.0.0.1 6379（之前被選舉出來的 master）；
i.+failover-state-select-slave master mymaster 127.0.0.1 6379（Leader 開始查找合適的slave）；
j.+selected-slave slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379 （leader已經找到合適的 slave）；
k.+failover-state-send-slaveof-noone slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379（Leader 向 slave 發送“slaveof no one”指令，此時 slave 已經完成角色轉換，此 slave 即為 master）；
l.+failover-state-wait-promotion slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379（等待其他 sentinel 確認 slave）；
m.+promoted-slave slave 127.0.0.1:63792 127.0.0.1 63792 @ mymaster 127.0.0.1 6379（確認成功）；
n.+failover-state-reconf-slaves master mymaster 127.0.0.1 6379 （開始對slaves進行reconfig 操作）；
o.+slave-reconf-sent slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 6379 （向指定的 slave 發送“slaveof”指令，告知此 slave 跟隨新的 master）；
p. +slave-reconf-inprog slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 6379（此 slave 正在執行 slaveof + SYNC 過程，如過 slave 收到“+slave-reconf-sent”之後將會執行 slaveof 操作，循環 n）；
q.+slave-reconf-done slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 6379（此 slave 同步完成，此後 leader 可以繼續下一個 slave 的 reconfig 操作）；
r.+failover-end master mymaster 127.0.0.1 6379（故障轉移結束）；
s.+switch-master mymaster 127.0.0.1 6379 127.0.0.1 63792（故障轉移成功後，各個sentinel 實例開始監控新的 master）；
t.+slave slave 127.0.0.1:63791 127.0.0.1 63791 @ mymaster 127.0.0.1 63792（下面幾步在給新的 master 加入 slave）；
u.+slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 63792；
v.+sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 63792。