有道无术，术尚可求，有术无道，止于术。

本系列Redis 版本 7.2.5

源码地址：https://gitee.com/pearl-organization/study-redis-demo

1. 概述

官方文档

主从复制模式常用于数据备份和读写分离，当主节点故障时，需要人工干预来处理主节点故障和从节点的升级，在实际应用中，可用性并不高。

Redis 提供了基于哨兵（Sentinel）的高可用解决方案，Sentinel是一个运行在特殊模式下的 Redis 服务端，本身不存储任何数据，而是作为主从复制模式下的监控和管理工具。当主节点出现故障时，可以提供自动故障转移功能，从而保证 Redis 服务的连续性和稳定性。

核心功能：

• 监控：持续检查主节点和从节点实例是否按预期工作
• 通知：可以通过 API 通知系统管理员或其他计算机程序，被监控的Redis实例出现问题
• 自动故障转移：如果主节点未按预期工作，启动故障转移过程，将其中一个从节点被提升为主节点，其他的从节点重新配置使用新的主节点，并且通知在连接时使用的新地址
• 配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

2. 工作原理

2.1 监控

Redis Sentinel 在启动完成后，首先需要连接到到主从节点进行监控：

在 Sentinel 配置文件中，首先需要配置主节点的地址，首次上线时，会根据该地址连接到主节点，并定期（通常是每1秒）向主节点发送 PING 命令来检查其状态。

Sentinel 连接到主节点后，还会通过 INFO 命令获取所有从节点的地址信息，建立和从节点的连接，并同样采用心跳机制进行状态检查。

多个 Sentinel 节点之间，也需要进行通信，会在主节点中建立一个 __sentinel__:hello 专用通道，利用发布订阅机制进行数据交互。可以使用可视化工具查看：

2.2 标记下线

当某个 Sentinel 节点发送 PING 命令后，主节点在规定的时间内没有响应，则会标记为主观下线（Subjectively Down）状态，其他 Sentinel 节点同样也会检测到主节点下线，并标记为主观下线。当主节点被足够数量的 Sentinel 节点都标记为 S_DOWN ，则标记为客观下线（Objectively Down）状态。

在 sentinel monitor 配置项中，可以设置主节点被多少个 Sentinel 标记为 S_DOWN 时，则标记为O_Down：

sentinel monitor mymaster 127.0.0.1 6379 2

从主观下线到客观下线，需要多个哨兵达成一致意见，才能认为主节点客观上已经宕掉，这一步骤是为了防止单个 Sentinel 节点的误判。

2.3 哨兵领袖

当主节点被判定为客观下线后，哨兵节点之间会进行投票选举，以选出哨兵领袖（Leader Sentinel），负责后续的故障转移工作。

整个选举过程基于 Raft 算法，当半数以上的哨兵投票通过后就认定该哨兵为哨兵领袖，所以一般将哨兵数量部署为单数，避免脑裂。

2.4 新的主节点

Leader Sentinel 会在从节点中，选择一个新的主节点，选择的标准一般有：

• 响应速度，慢的就会被优先过滤掉，说明健壮性不够
• 节点配置的优先级，优先级越高，越容易被选中
• 数据偏移量，偏移量越大，说明数据复制的完整度越高
• 节点创建时间，越早创建的节点，会优先选择（ 根据RunId 排序）

选出新的主节点后，Leader Sentinel 会调用 REPLICAOF 命令将选出的新节点升级为主节点，其他的从节点更新配置信息，并连接到新的主节点，并确保和新主节点之间的数据同步。

2.5 通知更新

Leader Sentinel 通过发布订阅通知其他哨兵节点，还可以通过 API 或者脚本发送通知，报告集群的状态变化和故障情况。

3. 搭建演示

数据节点直接使用之前搭建的一主两从环境，在此基础上搭建三个哨兵节点，简要部署架构图如下：

所有节点网络访问地址如下 ：

• 主节点：192.168.56.101:6379
• 从节点一：192.168.56.102:6379
• 从节点二：192.168.56.103:6379
• 哨兵节点一：192.168.56.104:26379
• 哨兵节点二：192.168.56.105:26379
• 哨兵节点三：192.168.56.106:26379

3.1 安装

Redis 7.x 系列【2】单机部署
Redis 7.x 系列【21】主从复制

Redis Sentinel也是一个特殊的 Redis 服务端，安装方法和普通的 Redis 一样，参考上面的文档，在三台哨兵服务器上安装即可。

3.2 修改配置

接下来需要修改所有哨兵节点的配置文件，首先从源码中将 sentinel.conf 配置文件复制到配置目录：

[root@localhost /]# mkdir /etc/redis
[root@localhost /]# cp ~/redis-7.2.5/sentinel.conf /etc/redis/
[root@localhost bin]# vim sentinel.conf

三个哨兵节点都需要修改配置，首先允许后台启动：

daemonize yes

配置当前监控的主节点的名称、IP、端口，以及进行故障转移的最少的投票数：

sentinel monitor mymaster 192.168.56.101 6379 2

如果主从节点设置了密码，还需要配置主节点名称、认证密码 （主从密码需要保持一致）：

sentinel auth-pass mymaster 123456

可以配置 Sentinel 节点的密码（其他哨兵节点的密码需要保持一致）：

requirepass entinel123456

3.3 启动

这里直接使用命令启动，先启动所有主从复制节点，再启动所有哨兵节点：

[root@localhost bin]# cd /usr/local/bin
[root@localhost bin]# ./redis-sentinel /etc/redis/sentinel.conf

3.4 测试

使用 ./redis-cli 连接任一哨兵节点：

[root@localhost bin]# ./redis-cli -p 26379
127.0.0.1:26379> auth sentinel123456
OK

输入 info sentinel 查看所有哨兵信息，可以看到当前连接的主节点地址为 192.168.56.101:6379 ，以及从节点和哨兵节点的数量：

127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.56.101:6379,slaves=2,sentinels=3

在主节点服务器上，直接 kill 掉主节点进程：

[root@localhost bin]# ps -ef | grep redis
root     16305     1  0 01:05 ?        00:00:29 ./redis-server *:6379
root     19902 19252  0 11:18 pts/2    00:00:00 grep --color=auto redis
[root@localhost bin]# kill 16305

再次执行 info sentinel 命令，可以看到主节点地址变成了 192.168.56.102:6379 ，自动进行了故障转移，并选举了新的主节点（当之前下线的主节点重新连接后，会降级为从节点）：

127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.56.102:6379,slaves=3,sentinels=3

查看 sentinel.conf 配置文件，可以看到自动更新了主节点：

还会自动更新从节点 redis.conf 配置文件：