哨兵模式

架构

redis 的集群方案大致有三种：

• redis cluster 集群方案；
• master/slave 主从方案；
• 哨兵模式来进行主从替换以及故障恢复。

sentinel（哨兵）是用于监控 redis 集群中 master 状态的工具，是 Redis 的高可用性解决方案，sentinel 哨兵模式已经被集成在 redis2.4 之后的版本中。

sentinel 本身是一个独立运行的进程，它能监控 master-slave 集群，发现 master 宕机后能进行自动切换。sentinel 可以让 redis 实现主从复制，当一个集群中的 master 失效之后，sentinel 可以选举出一个新的 master 用于自动接替 master 的工作，集群中的其他 redis 服务器自动指向新的 master 同步数据。一般建议 sentinel 采取奇数台，防止某一台 sentinel 无法连接到 master 导致误切换。

工作流程

sentinel 的主要作用：

1. master 状态检测；
2. 如果 master 异常，则会进行 master-slave 切换，将其中一个 slave 作为 master，将之前的 master 作为 slave；
3. master-slave 切换后，master_redis.conf、slave_redis.conf 和 sentinel.conf 的内容都会发生改变，即 master_redis.conf 中会多一行 slaveof 的配置，sentinel.conf 的监控目标会随之调换。

sentinel 工作方式：

1. 每个 sentinel 以每秒钟一次的频率向它所知的 master，slave 以及其他 sentinel 实例发送一个 ping 命令；
2. 如果一个实例（instance）距离最后一次有效回复 ping 命令的时间超过 own-after-milliseconds 选项所指定的值，则这个实例会被 sentinel 标记为主观下线；
3. 如果一个 master 被标记为主观下线，则正在监视这个 master 的所有 sentinel 要以每秒一次的频率确认 master 的确进入了主观下线状态；
4. 当有足够数量的 sentinel（大于等于配置文件指定的值）在指定的时间范围内确认 master 的确进入了主观下线状态，则 master 会被标记为客观下线；
5. 在一般情况下，每个 sentinel 会以每 10 秒一次的频率向它已知的所有 master，slave 发送 info 命令；
6. 当 master 被 sentinel 标记为客观下线时，sentinel 向下线的 master 的所有 slave 发送 info 命令的频率会从 10 秒一次改为每秒一次；
7. 若没有足够数量的 sentinel 同意 master 已经下线，master 的客观下线状态就会被移除。 若 master 重新向 sentinel 的 ping 命令返回有效回复，master 的主观下线状态就会被移除。

sentinel 在内部有 3 个定时任务：

1. 每 10 秒每个 sentinel 会对 master 和 slave 执行 info 命令，这个任务达到两个目的：

   • 发现 slave 节点
   • 确认主从关系

2. 每 2 秒每个 sentinel 通过 master 节点的 channel 交换信息（pub/sub）。master 节点上有一个发布订阅的频道(sentinel:hello)。sentinel 节点通过 sentinel:hello 频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。

3. 每 1 秒每个 sentinel 对其他 sentinel 和 redis 节点执行 ping 操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

主观下线

所谓主观下线（subjectively down， 简称 sdown）指的是单个 sentinel 实例对服务器做出的下线判断，即单个 sentinel 认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在 down-after-milliseconds 给定的毫秒数之内， 没有返回 sentinel 发送的 ping 命令的回复， 或者返回一个错误， 那么 sentinel 将这个服务器标记为主观下线。

客观下线

客观下线（objectively down， 简称 odown）指的是多个 sentinel 实例在对同一个服务器做出 sdown 判断， 并且通过 sentinel is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断，然后开启 failover。客观下线就是说只有在足够数量的 sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（odown）。只有当 master 被认定为客观下线时，才会发生故障迁移。

配置

服务器信息

主节点：10.124.5.207

从节点：10.124.5.198

redis：redis-6.2.7

安装

# 去官网检查最新版本，yum 安装的版本较低，不推荐
root@controller1:~# wget http://download.redis.io/releases/redis-6.2.7.tar.gz
root@controller1:~# tar -xzf redis-6.2.7.tar.gz
root@controller1:~# cd redis-6.2.7/
root@controller1:~/redis-6.2.7# make && make install

配置

root@controller1:~/redis-6.2.7# mkdir -p /usr/local/redis/data
root@controller1:~/redis-6.2.7# mkdir -p /usr/local/redis/sentinel_data
root@controller1:~/redis-6.2.7# cp redis.conf /usr/local/redis/
root@controller1:~/redis-6.2.7# cp sentinel.conf /usr/local/redis/

主节点 redis.conf：

bind 0.0.0.0
port 6379
daemonize yes
pidfile /usr/local/redis/redis.pid
logfile "/usr/local/redis/redis.log"
dir /usr/local/redis/data			

从节点 redis.conf：

bind 0.0.0.0
port 6379
daemonize yes
pidfile /usr/local/redis/redis.pid
logfile "/usr/local/redis/redis.log"
dir /usr/local/redis/data
slaveof 10.124.5.207 6379

主、从节点的 sentinel.conf 都为：

bind 0.0.0.0
port 26379
daemonize yes
pidfile /usr/local/redis/sentinel.pid
logfile "/usr/local/redis/sentinel.log"
dir /usr/local/redis/sentinel_data

sentinel monitor mymaster 10.124.5.207 6379 1
sentinel down-after-milliseconds mymaster 3000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes

sentinel monitor mastername ip port quorum

该配置定义了判断 master 客观下线的方式：

1. mastername 这个是对某个 master+slave 组合的一个区分标识，一套 sentinel 是可以监听多套 master+slave 这样的组合的；

2. ip 和 port 就是 master 节点的 ip 和 端口号；

3. quorum 这个参数是进行客观下线的一个依据，至少有 quorum 个 sentinel 主观的认为这个 master 有故障，才会对这个 master 进行下线以及故障转移。

sentinel down-after-milliseconds mastername timeout

该配置是判断主观下线的一个依据，mastername 区分标识，timeout 是一个毫秒值，表示如果这台 sentinel 超过 timeout 这个时间都无法连通 master 包括 slave（slave 不需要客观下线，因为不需要故障转移）的话，就会主观认为该 master 已经下线（实际下线需要客观下线的判断通过才会下线）。

测试

数据测试

向主节点发送数据，在从节点中查询：

alex@WXIE-M-393D ~ % redis-cli -h 10.124.5.207
10.124.5.207:6379> set test 123
OK

alex@WXIE-M-393D ~ % redis-cli -h 10.124.5.198 
10.124.5.198:6379> get test
"123"

宕机测试

主节点 shutdown，查看是否发生切换：

# 10.124.5.207 shutdown 主节点
root@controller1:/usr/local/redis# ps -ef|grep redis
root       79739       1  0 11:45 ?        00:00:00 redis-server 0.0.0.0:6379
root       79760       1  0 11:46 ?        00:00:00 redis-sentinel 0.0.0.0:6380 [sentinel]
root       79778   75169  0 11:49 pts/0    00:00:00 grep --color=auto redis
root@controller1:/usr/local/redis# kill -9 79739
root@controller1:/usr/local/redis# ps -ef|grep redis
root       79760       1  0 11:46 ?        00:00:13 redis-sentinel 0.0.0.0:6380 [sentinel]
root       79807   75169  0 12:40 pts/0    00:00:00 grep --color=auto redis

# 10.124.5.198 查看从节点信息
root@controller2:/usr/local/redis# cat redis.log 
22740:S 07 Nov 2022 11:52:26.432 * MASTER <-> REPLICA sync: Finished with success
22740:S 07 Nov 2022 12:40:37.674 # Connection with master lost.
22740:S 07 Nov 2022 12:40:37.674 * Caching the disconnected master state.
22740:S 07 Nov 2022 12:40:37.674 * Reconnecting to MASTER 10.124.5.207:6379
22740:S 07 Nov 2022 12:40:37.674 * MASTER <-> REPLICA sync started
22740:S 07 Nov 2022 12:40:37.674 # Error condition on socket for SYNC: Connection refused
22740:S 07 Nov 2022 12:40:38.217 * Connecting to MASTER 10.124.5.207:6379
22740:S 07 Nov 2022 12:40:38.217 * MASTER <-> REPLICA sync started
22740:S 07 Nov 2022 12:40:38.218 # Error condition on socket for SYNC: Connection refused
22740:M 07 Nov 2022 12:40:38.932 * Discarding previously cached master state.
22740:M 07 Nov 2022 12:40:38.932 # Setting secondary replication ID to 287cfb56ef8b4aeaf8cd24e03e15233d11a34d9f, valid up to offset: 394628. New replication ID is 47753363b21dd61a75aa40893ede060ffd718fde
22740:M 07 Nov 2022 12:40:38.932 * MASTER MODE enabled (user request from 'id=6 addr=10.124.5.198:34285 laddr=10.124.5.198:6379 fd=10 name=sentinel-bda84617-cmd age=2882 idle=0 flags=x db=0 sub=0 psub=0 multi=4 qbuf=188 qbuf-free=40766 argv-mem=4 obl=45 oll=0 omem=0 tot-mem=61468 events=r cmd=exec user=default redir=-1')
22740:M 07 Nov 2022 12:40:38.942 # CONFIG REWRITE executed with success.

# 也可以登录查看，但是通常需要等待大于 sentinel failover-timeout mymaster 180000 的时间
alex@WXIE-M-393D ~ % redis-cli -h 10.124.5.198
10.124.5.198:6379> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:7147ad909c787dc42a6ebe5825119d19a721c0d2
master_replid2:62813525645534dec7ed1a4a87ecd0837d823fad
master_repl_offset:15434
second_repl_offset:9991
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:15434

发现日志中 MASTER MODE enabled ，说明 10.124.5.198 已经从 slave 切换为 master。

此时，再恢复 10.124.5.207 的 redis 服务，查看其日志情况：

root@controller1:/usr/local/redis# redis-server redis.conf 
root@controller1:/usr/local/redis# ps -ef|grep redis
root       80018       1  0 13:01 ?        00:00:03 redis-sentinel 0.0.0.0:26379 [sentinel]
root       80062       1  0 13:13 ?        00:00:00 redis-server 0.0.0.0:6379
root       80068   75169  0 13:13 pts/0    00:00:00 grep --color=auto redis

alex@WXIE-M-393D ~ % redis-cli -h 10.124.5.207 
10.124.5.207:6379> info replication
# Replication
role:slave
master_host:10.124.5.198
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:484515
slave_repl_offset:484515
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:47753363b21dd61a75aa40893ede060ffd718fde
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:484515
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:457441
repl_backlog_histlen:27075

似乎 10.124.5.207 没有恢复为主节点，需要后续继续研究。

…后续：

参考了一些文章，似乎原来的主节点宕机重启后，不会恢复成为主节点，而是成为现在主节点的从节点。参考内容如下：

故障转移分为三个步骤：

1. 从下线的主服务的所有从服务里面挑选一个从服务，将其转成主服务。sentinel 状态数据结构中保存了主服务的所有从服务信息，领头 sentinel 按照如下的规则从从服务列表中挑选出新的主服务；

• 删除列表中处于下线状态的从服务；
• 删除最近 5 秒没有回复过领头 sentinel info 信息的从服务；
• 删除与已下线的主服务断开连接时间超过 down-after-milliseconds*10 毫秒的从服务，这样就能保留从的数据比较新（没有过早的与主断开连接）；

领头 sentinel 从剩下的从列表中选择优先级高的，如果优先级一样，选择偏移量最大的（偏移量大说明复制的数据比较新），如果偏移量一样，选择运行 id 最小的从服务。

2. 已下线主服务的所有从服务改为复制新的主服务。挑选出新的主服务之后，领头 sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，复制新 master。

3. 将已下线的主服务设置成新的主服务的从服务，当其回复正常时，复制新的主服务，变成新的主服务的从服务。同理，当已下线的服务重新上线时，sentinel 会向其发送 slaveof 命令，让其成为新主的从。

参考

1. Redis哨兵模式(sentinel)学习总结及部署记录(主从复制、读写分离、主从切换)

2. Redis哨兵模式搭建(一主一从,两哨兵)

3. redis哨兵，原master节点重启后，无法变成新master节点的slave