在上一篇博客----Redis詳解(八)------ 主從復制,我們簡單介紹了Redis的主從架構,但是這種主從架構存在一個問題,當主服務器宕機,從服務器不能夠自動切換成主服務器,為了解決這個問題,我們又介紹了哨兵模式,本篇博客我們繼續深入的介紹一下這種模式.

1、架構圖

2、服務器列表

3、搭建主從模式

①、主要配置項

主服務器(上圖的Node1)配置文件 redis.config 主要配置項:

#配置端口

port 6379

#以守護進程模式啟動

daemonize yes

#pid的存放文件

pidfile /var/run/redis_6379.pid

#日志文件名

logfile "redis_6379.log"

#存放備份文件以及日志等文件的目錄

dir "/opt/redis/data"

從服務器配置文件主要配置項基本和主服務器保持一致,需要修改端口 port ;另外存放位置和日志文件名也可以根據需要修改.

為了表示主從關系,還需要在從服務器配置文件中添加一行重要配置:

#配置主服務器IP,端口

slaveof 192.168.14.101 6379

②、驗證主從關系

配置完成后,我們通過 redis-server redis.conf 命令啟動Redis.然后通過?redis-cli -p 端口 分別進入到各臺服務器的控制行頁面:

輸入如下命令:

info replication

三臺服務器打印結果如下:

由上圖可以看到,Node1 服務器作為主服務器,節點角色是 master,另外的兩臺從服務器,節點角色都是 slave.

另外還可以進行如下測試:可以在主服務器上添加一條數據,然后看看從服務器上是否能夠查到該數據.

③、問題

如果對于上面的測試,主服務器上添加的數據,從服務器上無法查詢到,可以查看前面配置的目錄/opt/redis/data 日志文件,有一種錯誤如下:

這是由于主服務器設置了登錄密碼,從服務器在向主服務器進行數據同步復制時,由于不知道主服務器密碼,導致連接不上,從而無法進行同步.

解決這個問題,需要明確兩個配置:

一.requreipass

設置redis的登錄密碼.

二.masterauth

針對master對應的slave節點設置的，在slave節點數據同步的時候用到。

建議,如果啟用Redis密碼校驗,最好將各個節點的masterauth和requirepass設置為相同的密碼;如果不設置為相同的,要注意slave節點masterauth和master節點requirepass的對應關系.

4、搭建哨兵模式

①、主要配置項

配置文件名稱為：sentinel.conf

#配置端口

port 26379

#以守護進程模式啟動

daemonize yes

#日志文件名

logfile "sentinel_26379.log"

#存放備份文件以及日志等文件的目錄

dir "/opt/redis/data"

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

sentinel monitor mymaster 192.168.14.101 6379 2

#30秒ping不通主節點的信息，主觀認為master宕機

sentinel down-after-milliseconds mymaster 30000

#故障轉移后重新主從復制，1表示串行，>1并行

sentinel parallel-syncs mymaster 1

#故障轉移開始，三分鐘內沒有完成，則認為轉移失敗

sentinel failover-timeout mymaster 180000

注意三臺服務器的端口配置.如果redis服務器配置了密碼連接,則要增加如下配置:

sentinel auth-pass mymaster 123

后面的123表示密碼.注意這行配置要配置到 sentinel monitor mymaster ip port 后面,因為名稱 mymaster要先定義.

②、啟動哨兵

redis-sentinel sentinel.conf

③、驗證主從自動切換

首先kill掉Redis 主節點.然后查看sentinel 日志:

上面截圖紅框框住的幾個重要信息,這里先介紹最后一行,switch-master mymaster 192.168.14.101 6379 192.168.14.103 6381 表示master服務器將由6379的redis服務切換為6381端口的redis服務器.

PS:+switch-master 表示切換主節點.

然后我們通過 info replication 命令查看 6381的redis服務器:

我們發現,6381的Redis服務已經切換成master節點了.

另外,也可以查看sentinel.conf 配置文件,里面的?sentinel monitor mymaster 192.168.14.101 6379 2 也自動更改為?sentinel monitor mymaster 192.168.14.103 6381 2 配置了.

5、Java客戶端連接哨兵集群

這里通過springboot項目來連接,代碼地址如下:

https://github.com/YSOcean/redis-sentinel.git

這里貼一下主要測試代碼:

PS:實際上springboot已經為我們注入了RedisTemplate,我們在實際項目中不用寫的像下面代碼這么麻煩,這樣寫是為了詳細的表明連接步驟.

//1.設置sentinel 各個節點集合

Set 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();

}

}

6、Java客戶端連接原理

①、結構圖

②、連接步驟

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

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

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

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

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

7、哨兵模式工作原理

①、三個定時任務

一.每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 時的配置文件來看:

#監控的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:切換從節點(原主節點降為從節點)

總結

以上是生活随笔為你收集整理的jedispool redis哨兵_Redis详解（九）------ 哨兵(Sentinel)模式详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。