Redis 哨兵模式Java 操作

//1.設置sentinel 各個節點集合
Set<String> sentinelSet = new HashSet<>();
sentinelSet.add("192.168.14.101:26379");
sentinelSet.add("192.168.14.102:26380");
sentinelSet.add("192.168.14.103:26381");
 
//2.設置jedispool 連接池配置文件
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(10);
config.setMaxWaitMillis(1000);
 
//3.設置mastername,sentinelNode集合,配置文件,Redis登錄密碼
JedisSentinelPool jedisSentinelPool = new JedisSentinelPool("mymaster",sentinelSet,config,"123");
Jedis jedis = null;
try {
    jedis = jedisSentinelPool.getResource();
    //獲取Redis中key=hello的值
    String value = jedis.get("hello");
    System.out.println(value);
} catch (Exception e) {
    e.printStackTrace();
} finally {
    if(jedis != null){
        jedis.close();
    }
}

 

②、連接步驟 

　　一.客戶端遍歷所有的 Sentinel 節點集合,獲取一個可用的 Sentinel 節點.

　　二.客戶端向可用的 Sentinel 節點發送 get-master-addr-by-name 命令,獲取Redis Master 節點.

　　三.客戶端向Redis Master節點發送role或role replication 命令,來確定其是否是Master節點,並且能夠獲取其 slave節點信息.

　　四.客戶端獲取到確定的節點信息后,便可以向Redis發送命令來進行后續操作了

　　需要注意的是:客戶端是和Sentinel來進行交互的,通過Sentinel來獲取真正的Redis節點信息,然后來操作.實際工作時,Sentinel 內部維護了一個主題隊列,

        用來保存Redis的節點信息,並實時更新,

        客戶端訂閱了這個主題,然后實時的去獲取這個隊列的Redis節點信息

      哨兵模式工作原理

　　①、三個定時任務

　　一.每10秒每個 sentinel 對master 和 slave 執行info 命令:該命令第一個是用來發現slave節點,第二個是確定主從關系.

　　二.每2秒每個 sentinel 通過 master 節點的 channel(名稱為_sentinel_:hello) 交換信息(pub/sub):用來交互對節點的看法(后面會介紹的節點主觀下線和客觀下線)以及自身信息.

　　三.每1秒每個 sentinel 對其他 sentinel 和 redis 執行 ping 命令,用於心跳檢測,作為節點存活的判斷依據.

　　②、主觀下線和客觀下線

　　一.主觀下線

　　SDOWN:subjectively down,直接翻譯的為”主觀”失效,即當前sentinel實例認為某個redis服務為”不可用”狀態.

　　二.客觀下線

　　ODOWN:objectively down,直接翻譯為”客觀”失效,即多個sentinel實例都認為master處於”SDOWN”狀態,那么此時master將處於ODOWN,ODOWN可以簡單理解為master已經被集群確定為”不可用”,將會開啟故障轉移機制.

　　結合我們第4點搭建主從模式,驗證主從切換時,kill掉Redis主節點,然后查看 sentinel 日志,如下:

　　

　　發現有類似 sdown 和 odown 的日志.在結合我們配置 sentinel 時的配置文件來看:

1 2	#監控的IP 端口號 名稱 sentinel通過投票后認為mater宕機的數量，此處為至少2個 sentinel monitor mymaster 192.168.14.101 6379 2

　　最后的 2 表示投票數,也就是說當一台 sentinel 發現一個 Redis 服務無法 ping 通時,就標記為 主觀下線 sdown;同時另外的 sentinel 服務也發現該 Redis 服務宕機,也標記為 主觀下線,當多台 sentinel (大於等於2,上面配置的最后一個)時,都標記該Redis服務宕機,這時候就變為客觀下線了,然后進行故障轉移.

　　③、故障轉移

　　故障轉移是由 sentinel 領導者節點來完成的(只需要一個sentinel節點),關於 sentinel 領導者節點的選取也是每個 sentinel 向其他 sentinel 節點發送我要成為領導者的命令,超過半數sentinel 節點同意,並且也大於quorum ,那么他將成為領導者,如果有多個sentinel都成為了領導者,則會過段時間在進行選舉.

　　sentinel 領導者節點選舉出來后,會通過如下幾步進行故障轉移:

　　一.從 slave 節點中選出一個合適的 節點作為新的master節點.這里的合適包括如下幾點:

　　　　1.選擇 slave-priority(slave節點優先級)最高的slave節點,如果存在則返回,不存在則繼續下一步判斷.

　　　　2.選擇復制偏移量最大的 slave 節點(復制的最完整),如果存在則返回,不存在則繼續.

　　　　3.選擇runId最小的slave節點(啟動最早的節點)

　　二.對上面選出來的 slave 節點執行 slaveof no one 命令讓其成為新的 master 節點.

　　三.向剩余的 slave 節點發送命令,讓他們成為新master 節點的 slave 節點,復制規則和前面設置的 parallel-syncs 參數有關.

　　四.更新原來master 節點配置為 slave 節點,並保持對其進行關注,一旦這個節點重新恢復正常后,會命令它去復制新的master節點信息.(注意:原來的master節點恢復后是作為slave的角色)

　　可以從 sentinel 日志中出現的幾個消息來進行查看故障轉移:

　　1.+switch-master:表示切換主節點(從節點晉升為主節點)

　　2.+sdown:主觀下線

　　3.+odown:客觀下線

　　4.+convert-to-slave:切換從節點(原主節點降為從節點)