Redis-Sentinel—實現Redis高可用之哨兵模式

廢話簡論

Redis高可用之哨兵模式它就是,當你的reids掛掉了之後,它可以自己切換到其他redis上.不影響用戶的正常使用.

簡述Sentinel:

Sentinel具有四個特點: 監控,通知,自動故障轉移,配置提供者

監控：哨兵不斷的檢查master和slave是否正常的運行。
通知：當監控的某臺Redis實例發生問題時，可以通過API通知系統管理員和其他的應用程序。
自動故障轉移：如果一個master不正常運行了，哨兵可以啓動一個故障轉移進程，將一個slave升級成爲master，其他的slave被重新配置使用新的master，並且應用程序使用Redis服務端通知的新地址。
配置提供者：哨兵作爲Redis客戶端發現的權威來源：客戶端連接到哨兵請求當前可靠的master的地址。如果發生故障，哨兵將報告新地址。

這是Redis的使用API,和Sentinel的鏈接.

spring Data Redis API : https://docs.spring.io/spring-data/redis/docs/current/api/

Redis Sentinel :http://redisdoc.com/topic/sentinel.html

下面直接上Dome

開始

準備環境:

一個健壯的部署需要三個哨兵實例,在這裏我使用了VMware CentOs64 虛擬機.三個Redis.

部署流程:

下載並安裝三個Redis
修改redis.conf配置文件,(主要是修改redis的 <protected-mode> redis是否受保護 , <port> 端口號 ,<bind> redis指定的訪問地址, <daemonize> 是否後臺運行)
修改sentinel.conf( <protected-mode> sentinel是否受保護, <port> sentinel的端口號,<daemonize> 是否後臺運行 ,logfile "sentinel的日誌文件路徑" , sentinel monitor mymaster 192.168.111.129 6380 2 指定的master 的地址/端口/選舉master的認同機器的數量 ,sentinel down-after-milliseconds mymaster 6000 檢測主機掛掉後幾秒開始故障轉移, sentinel failover-timeout mymaster 60000 故障轉移需要的最長時間, )
運行三個redis,運行三個Sentinel.
驗證:殺死master的redis-server. 是否在設置的時間之後完成故障轉移.
分析Sentinel的日誌信息.分析問題.

貼流程的細節演示:

前提:make好redis到指定的目錄,分好運行的/bin 和配置文件的/etc ,基本的常識不再贅述..

使用的三個reids 分別是 redis1,redis2,redis3.

[root@MyVMS-CentOS64-NO1 local]# cd /usr/local/
[root@MyVMS-CentOS64-NO1 local]# ll
總用量 60
drwxr-xr-x. 2 root root 4096 9月  12 19:54 bin
drwxr-xr-x. 2 root root 4096 9月  23 2011 etc
drwxr-xr-x. 2 root root 4096 9月  23 2011 games
drwxr-xr-x. 2 root root 4096 9月  23 2011 include
drwxr-xr-x. 2 root root 4096 9月  23 2011 lib
drwxr-xr-x. 2 root root 4096 9月  23 2011 lib64
drwxr-xr-x. 2 root root 4096 9月  23 2011 libexec
drwxr-xr-x. 6 root root 4096 9月  15 08:17 redis1 
drwxr-xr-x. 6 root root 4096 9月  15 07:40 redis2
drwxr-xr-x. 6 root root 4096 9月  15 08:17 redis3
drwxr-xr-x. 2 root root 4096 9月  23 2011 sbin
drwxr-xr-x. 5 root root 4096 9月  13 01:22 share
drwxr-xr-x. 2 root root 4096 9月  23 2011 src
drwxr-xr-x. 3 root root 4096 9月  13 13:06 tomcat1

下面是自己創建的redis1的層級,方便區分.redis-4.0.11是make後的redis.

[root@MyVMS-CentOS64-NO1 local]# cd /usr/local/redis1/
[root@MyVMS-CentOS64-NO1 redis1]# ll
總用量 16
drwxr-xr-x. 2 root root 4096 9月  15 12:12 bin
drwxr-xr-x. 2 root root 4096 9月  15 12:41 etc
drwxr-xr-x. 2 root root 4096 9月  15 08:17 log
drwxrwxr-x. 6 root root 4096 9月  12 21:17 redis-4.0.11

/bin的內容.

[root@MyVMS-CentOS64-NO1 redis1]# cd /usr/local/redis1/bin/
[root@MyVMS-CentOS64-NO1 bin]# ll
總用量 35484
-rw-r--r--. 1 root root     197 9月  15 12:12 dump.rdb
-rwxr-xr-x. 1 root root 5597510 9月  12 19:52 redis-benchmark
-rwxr-xr-x. 1 root root 8331160 9月  12 19:52 redis-check-aof
-rwxr-xr-x. 1 root root 8331160 9月  12 19:52 redis-check-rdb
-rwxr-xr-x. 1 root root 5737866 9月  12 19:52 redis-cli
lrwxrwxrwx. 1 root root      12 9月  12 19:52 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 8331160 9月  12 19:52 redis-server

/etc下的配置文件

[root@MyVMS-CentOS64-NO1 bin]# cd /usr/local/redis1/etc/
[root@MyVMS-CentOS64-NO1 etc]# ll
總用量 72
-rw-rw-r--. 1 root root 58877 9月  15 11:37 redis.conf
-rw-r--r--. 1 root root  8484 9月  15 11:37 sentinel.conf

/log下的日誌文件

[root@MyVMS-CentOS64-NO1 etc]# cd /usr/local/redis1/log/
[root@MyVMS-CentOS64-NO1 log]# ll
總用量 16
-rw-r--r--. 1 root root 14084 9月  15 11:51 redis-sentinel_6380.log

另外兩個目錄層級也一樣.

搭建高可用Redis 一主兩從
Redis-1 Redis-2 Redis-3
6380 6381 6382

啓動三個獨立的Redis,

./usr/local/redis1/bin/redis-server /usr/local/redis1/etc/redis.conf

./usr/local/redis2/bin/redis-server /usr/local/redis2/etc/redis.conf

./usr/local/redis3/bin/redis-server /usr/local/redis3/etc/redis.conf

這裏我們把reids1,端口爲6380作爲master,執行下面命令,

命令 6381 爲 6380 的僕人.

./usr/local/redis2/bin/redis-cli -h 192.168.111.129 -p 6381 slaveof 192.168.111.129 6380

命令 6382 爲 6380 的僕人.

./usr/local/redis3/bin/redis-cli -h 192.168.111.129 -p 6382 slaveof 192.168.111.129 6380

這裏是使用了一臺服務器,部署了三個redis,所以需要修改端口號.

啓動三個哨兵:

這裏說明一下,在三個哨兵Sentinel.conf的配置文件中需要注意的地方.其他配置不懂的地方去看上面的Sentinel的官網,貼上配置文件. 哨兵只需要監聽主master的redis 就可以知道master下的主從配置.從而找到從redis.

redis1中的Sentinel.conf部分配置.
---
sentinel monitor mymaster 192.168.111.129 6380 2  //這裏的都寫上你的主master的地址和端口.
sentinel down-after-milliseconds mymaster 6000
sentinel failover-timeout mymaster 60000
---

cd /
./usr/local/redis1/bin/redis-server /usr/local/redis1/etc/sentinel.conf --sentinel
cd /
./usr/local/redis2/bin/redis-server /usr/local/redis2/etc/sentinel.conf --sentinel
cd /
./usr/local/redis3/bin/redis-server /usr/local/redis3/etc/sentinel.conf --sentinel

這裏啓動的redis 和 sentinel 都是以後臺運行(daemonize yes)的方式進行的.所以需要查看三個Sentinel的日誌.

[root@MyVMS-CentOS64-NO1 log]# ps -ef | grep redis
root     38130 37887  0 10:45 pts/0    00:00:00 tail -f /usr/local/redis3/log/redis-sentinel_6382.log
root     38131 38088  0 10:45 pts/2    00:00:00 tail -f /usr/local/redis2/log/redis-sentinel_6381.log
root     38132 38111  0 10:45 pts/3    00:00:00 tail -f /usr/local/redis1/log/redis-sentinel_6380.log
root     38274     1  0 11:05 ?        00:00:19 ./usr/local/redis1/bin/redis-server 192.168.111.129:6380
root     38285     1  0 11:05 ?        00:00:21 ./usr/local/redis3/bin/redis-server 192.168.111.129:6382
root     38291     1  0 11:05 ?        00:00:31 ./usr/local/redis1/bin/redis-server *:26380 [sentinel]
root     38299     1  0 11:06 ?        00:00:31 ./usr/local/redis2/bin/redis-server *:26381 [sentinel]
root     38304     1  0 11:06 ?        00:00:31 ./usr/local/redis3/bin/redis-server *:26382 [sentinel]
root     38466     1  0 11:51 ?        00:00:14 ./usr/local/redis2/bin/redis-server 192.168.111.129:6381
root     38815 37710  0 13:24 pts/5    00:00:00 grep redis

查看一下誰是master . 下面是查看sentinel信息的一些命令 (需要在sentinel 客戶端下.)

[root@MyVMS-CentOS64-NO1 /]# cd /usr/local/redis1/bin/
[root@MyVMS-CentOS64-NO1 bin]# ./redis-cli -h 192.168.111.129 -p 26380
192.168.111.129:26380> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "192.168.111.129"
    5) "port"
    6) "6380" //他是master 
    7) "runid"
    8) "6b087ab930d63644997fdb6283224f23e3af62b0"
    9) "flags"
   10) "master"
   11) "link-pending-commands"
   12) "0"
   13) "link-refcount"
   14) "1"
   15) "last-ping-sent"
   16) "0"
   17) "last-ok-ping-reply"
   18) "675"
   19) "last-ping-reply"
   20) "675"
   21) "down-after-milliseconds"
   22) "6000"
   23) "info-refresh"
   24) "6839"
   25) "role-reported"
   26) "master"
   27) "role-reported-time"
   28) "363894"
   29) "config-epoch"
   30) "10"
   31) "num-slaves"
   32) "2"
   33) "num-other-sentinels"
   34) "2"
   35) "quorum"
   36) "2"
   37) "failover-timeout"
   38) "60000"
   39) "parallel-syncs"
   40) "1"

命令 : info sentinel.

192.168.111.129:26380> 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.111.129:6380,slaves=2,sentinels=3

下面是在redis客戶端下的查看信息命令:

[root@MyVMS-CentOS64-NO1 bin]# ./usr/local/redis1/bin/redis-cli -h 192.168.111.129 -p 6380
192.168.111.129:6380> info replication
# Replication
role:master //角色是mater
connected_slaves:2 //有兩臺slave 
slave0:ip=192.168.111.129,port=6381,state=online,offset=84653,lag=1
slave1:ip=192.168.111.129,port=6382,state=online,offset=84506,lag=1
master_replid:64cd5666c92af9c9539bb390b3585bc0bb640916
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:84653
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:84653

同樣查看一下在redis2服務的角色.

[root@MyVMS-CentOS64-NO1 /]# ./usr/local/redis2/bin/redis-cli -h 192.168.111.129 -p 6381
192.168.111.129:6381> info replication
# Replication
role:slave //在redis2下面的 6381 爲 slave .
master_host:192.168.111.129
master_port:6380 //master 爲 6380 
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:123258
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:64cd5666c92af9c9539bb390b3585bc0bb640916
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:123258
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:123258

OK ,到這裏主從關係很明顯了.查看一下哨兵的監聽情況.打開三個哨兵的日誌文件.

38304:X 15 Sep 13:34:13.838 * +reboot master mymaster 192.168.111.129 6380
38304:X 15 Sep 13:34:13.922 # -sdown master mymaster 192.168.111.129 6380
38304:X 15 Sep 13:34:13.922 # -odown master mymaster 192.168.111.129 6380
38304:X 15 Sep 13:34:19.217 * +reboot slave 192.168.111.129:6381 192.168.111.129 6381 @ mymaster 192.168.111.129 6380
38304:X 15 Sep 13:34:19.275 # -sdown slave 192.168.111.129:6381 192.168.111.129 6381 @ mymaster 192.168.111.129 6380
38304:X 15 Sep 13:34:21.975 * +reboot slave 192.168.111.129:6382 192.168.111.129 6382 @ mymaster 192.168.111.129 6380
38304:X 15 Sep 13:34:22.032 # -sdown slave 192.168.111.129:6382 192.168.111.129 6382 @ mymaster 192.168.111.129 6380

看到6381 , 6382 都是服從 6380 的. (主服務的 sdown 和 odown 出現的情況去看下說明吧.在故障轉移的時候這裏在分析日誌的時候需要注意一下)

sdown 和 sdown (主觀下線和客觀下線) .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 就會將這個服務器標記爲主觀下線。

服務都全部起起來了,日誌也已經跑起來了.天空變得很晴朗,心情也不錯..接下來就把主服務6380搞死.測試一下故障轉移.

立即執行:

redis-cli -p 6379 DEBUG sleep 30

這個命令將使master休眠30秒不能訪問。這主要是模仿master由於一些原因掛掉。

(或者直接 kill 掉主redis )

如果你檢查了Sentinel日誌，以應該能看到很多動作：

每個Sentinel檢查到master掛掉，有一個+sdown事件。
這個時間稍後升級到 +odown，這意味着多個(至少兩個以上)Sentinel商定了master不可到達的事實。
Sentinels投票選舉一個Sentinel啓動第一次故障轉移。
發生故障轉移。(下面貼上日誌)

日誌上面我已經用斜線備註了 redis的端口號.

------------redis1-----6380--
38304:X 15 Sep 14:01:15.476 # +sdown master mymaster 192.168.111.129 6380 //主觀下線
38304:X 15 Sep 14:01:19.100 # +new-epoch 12 //新時代的到來
38304:X 15 Sep 14:01:19.105 # +vote-for-leader 72ffd0c42052057fc72c530d8dd1211d167c69ca 12//投票
38304:X 15 Sep 14:01:19.749 # +odown master mymaster 192.168.111.129 6380 #quorum 3/2 //三臺Sentinel監聽確認客觀下線
38304:X 15 Sep 14:01:19.750 # Next failover delay: I will not start a failover before Sat Sep 15 14:03:19 2018 //開始故障轉移
38304:X 15 Sep 14:01:20.205 # +config-update-from sentinel 72ffd0c42052057fc72c530d8dd1211d167c69ca 192.168.111.129 26381 @ mymaster 192.168.111.129 6380 
38304:X 15 Sep 14:01:20.205 # +switch-master mymaster 192.168.111.129 6380 192.168.111.129 6382 
38304:X 15 Sep 14:01:20.206 * +slave slave 192.168.111.129:6381 192.168.111.129 6381 @ mymaster 192.168.111.129 6382
38304:X 15 Sep 14:01:20.207 * +slave slave 192.168.111.129:6380 192.168.111.129 6380 @ mymaster 192.168.111.129 6382
38304:X 15 Sep 14:01:22.717 # +sdown slave 192.168.111.129:6380 192.168.111.129 6380 @ mymaster 192.168.111.129 6382

---------------------------------------redis3----------6382----
38291:X 15 Sep 14:01:19.040 # +sdown master mymaster 192.168.111.129 6380
38291:X 15 Sep 14:01:19.096 # +new-epoch 12 
38291:X 15 Sep 14:01:19.103 # +vote-for-leader 72ffd0c42052057fc72c530d8dd1211d167c69ca 12
38291:X 15 Sep 14:01:19.106 # +odown master mymaster 192.168.111.129 6380 #quorum 3/2
38291:X 15 Sep 14:01:19.106 # Next failover delay: I will not start a failover before Sat Sep 15 14:03:19 2018
38291:X 15 Sep 14:01:20.203 # +config-update-from sentinel 72ffd0c42052057fc72c530d8dd1211d167c69ca 192.168.111.129 26381 @ mymaster 192.168.111.129 6380 
38291:X 15 Sep 14:01:20.204 # +switch-master mymaster 192.168.111.129 6380 192.168.111.129 6382
38291:X 15 Sep 14:01:20.204 * +slave slave 192.168.111.129:6381 192.168.111.129 6381 @ mymaster 192.168.111.129 6382 // 6381 服從 6382 
38291:X 15 Sep 14:01:20.204 * +slave slave 192.168.111.129:6380 192.168.111.129 6380 @ mymaster 192.168.111.129 6382  // 6380 服從 6382 
38291:X 15 Sep 14:01:26.236 # +sdown slave 192.168.111.129:6380 192.168.111.129 6380 @ mymaster 192.168.111.129 6382   //  // 6380 掛了 也要 服從 6382.

6380主掛了,6382侍從立馬上位爲主 . ( 這個選舉 leader 的規則,由配置可以修改 <slave-priority 100> 值越小越優先,0爲不參與選舉.)

下面看一下6382 現在的角色到底是不是主master??

[root@MyVMS-CentOS64-NO1 /]# ./usr/local/redis3/bin/redis-cli -h 192.168.111.129 -p 6382
192.168.111.129:6382> info replication
# Replication
role:master // 6382 的角色是master了.沒錯晉升了
connected_slaves:1  // 6380 掛了,現在只有一個 侍從了.
slave0:ip=192.168.111.129,port=6381,state=online,offset=669638,lag=1
master_replid:3ec08fb977346bdf70bb33dc53b75b507b19fe89
master_replid2:64cd5666c92af9c9539bb390b3585bc0bb640916
master_repl_offset:669785
second_repl_offset:351242
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:669785

使用Sentinel客戶端來查看一下.

[root@MyVMS-CentOS64-NO1 /]# ./usr/local/redis3/bin/redis-cli -h 192.168.111.129 -p 26382
192.168.111.129:26382> SENTINEL get-master-addr-by-name mymaster //獲取當前的master的名稱和地址
1) "192.168.111.129"
2) "6382"

故障轉移已經完成了.

敲黑板!當故障轉移完成後,完成後,完成後,纔去啓動剛纔已經掛掉的6380 redis .啓動後的6380 已經不再是曾經的master了,就算他再次復活也只是一個slave.

(這裏有在故障轉移時的坑,如果當你發現6380 master掛掉之後,Sentinel在準備故障轉移時,你手動啓動了6380.Sentinel的算法會凌亂的,結果就是三個redis沒有master.這時候需要全部重啓.).建議是當故障轉移完成後,方可啓動掛掉的master.

你想啊,全部的侍從都在仰視,準備新王登基,還未完成登基,突然曾經的王6380回來了.....是不是必定是一場精彩的戰鬥.此時羣龍無首...

Redis-Sentinel—實現Redis高可用之哨兵模式

廢話簡論

簡述Sentinel:

開始

使用c#強大的表達式樹實現對象的深克隆之解決循環引用的問題

GPT-4o 引領人機交互新風向，向量數據庫賽道沸騰了

free AI online tools All In One

痞子衡嵌入式：恩智浦i.MX RT1xxx系列MCU啓動那些事（12.A）- uSDHC eMMC啓動時間(RT1170)

基於Ubuntu-22.04安裝K8s-v1.28.2實驗（二）使用kube-vip實現集羣VIP訪問

企業大模型如何成爲自己數據的“百科全書”？

本地SSL證書過期輸入命令在IIS自動生成

.NET週刊【5月第2期 2024-05-12】

基於Ubuntu-22.04安裝K8s-v1.28.2實驗（一）部署K8s

基於Ubuntu-22.04安裝K8s-v1.28.2實驗（三）數據卷掛載NFS（網絡文件系統）

Redis-Sentinel—實現Redis高可用之哨兵模式

SprigBoot - JRebel for IntelliJ 熱部署集成

Spring Boot Redis-Sentinel—實現Redis高可用之哨兵模式

webSocket長連接實現demo(場景:掃碼自動跳轉登錄,或者替換輪詢)

解決你最痛苦的根本途徑--自律。

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結