【Redis核心原理篇4】Redis 哨兵模式：自动故障转移的实现原理

小可爱awo

976人浏览 · 2026-01-25 19:41:04

小可爱awo · 2026-01-25 19:41:04 发布

💻 Hello World, 我是予枫。

代码不止，折腾不息。作为一个正在升级打怪的 Java 后端练习生，我喜欢把踩过的坑和学到的招式记录下来。保持空杯心态，让我们开始今天的技术分享。

作为后端开发人员，我们在使用 Redis 构建缓存或分布式存储系统时，高可用性是绕不开的核心需求。Redis 主从复制可以解决数据备份和读写分离的问题，但主节点宕机后，需要人工介入切换从节点为主节点，这显然无法满足生产环境的 7×24 小时服务要求。

Redis Sentinel（哨兵模式）正是为解决这一痛点而生的高可用解决方案，它能够自动完成节点监控、故障检测、故障转移等核心工作。本文将从原理到实战，全面拆解 Redis 哨兵模式，帮你彻底掌握其工作机制与生产环境配置方法。

一、Redis 哨兵模式核心概念

Redis 哨兵是一个分布式系统，由一个或多个哨兵节点组成，它独立于 Redis 主从节点运行，主要作用是监控 Redis 集群状态，并在主节点故障时自动触发故障转移。

哨兵模式的核心依赖两个基础机制：

Redis 主从复制：哨兵需要基于主从集群才能工作，从节点会同步主节点的数据。
哨兵节点间的通信：哨兵节点之间会通过 Gossip 协议交换节点状态信息，通过投票机制达成故障共识。

二、哨兵的三大核心功能

哨兵模式的能力可以概括为监控、通知、故障转移，这三大功能环环相扣，构成了 Redis 高可用的核心链路。

1. 监控（Monitoring）

这是哨兵最基础的功能，哨兵节点会定期向 Redis 主节点、从节点发送 PING 命令，检查节点是否处于存活状态。

具体监控逻辑如下：

哨兵会以固定频率（默认 1 秒 1 次）向所有被监控的主从节点发送 PING 命令。
节点收到 PING 后，会返回 PONG 响应；如果节点因为网络故障、进程挂掉、阻塞等原因无法在指定时间内返回 PONG，哨兵会标记该节点为 “疑似宕机” 状态。
同时，哨兵节点之间也会互相监控，确保哨兵集群自身的可用性。

监控的核心价值是及时发现节点异常，为后续的故障判断和转移提供依据。

2. 通知（Notification）

当哨兵检测到节点状态变化时，会通过两种方式将信息同步给相关方：

向管理员通知：哨兵可以通过配置脚本，在节点发生故障（如主节点宕机、故障转移完成）时，触发邮件、短信或告警平台的通知，让运维人员及时知晓集群状态。
向客户端通知：哨兵内置了一个发布订阅机制，客户端可以订阅哨兵的特定频道（如 +switch-master），实时获取集群的主节点变更信息。当主节点切换后，客户端可以通过哨兵获取新的主节点地址，从而实现无感知切换。

通知功能的核心价值是打破信息孤岛，让运维和客户端都能实时感知集群状态变化。

3. 故障转移（Automatic Failover）

这是哨兵模式最核心、最复杂的功能，当主节点被判定为 “真正宕机” 后，哨兵会自动执行故障转移流程，将一个从节点升级为新的主节点，确保集群服务不中断。

完整的故障转移流程分为 5 步：

确认主节点宕机：哨兵集群达成共识，判定主节点为客观下线状态。
选举领导者哨兵：哨兵集群通过投票选举出一个 “领导者哨兵”，由它负责执行后续的故障转移操作（避免多个哨兵同时操作导致冲突）。
选择新主节点：领导者哨兵会从所有从节点中，筛选出最优的节点作为新主节点（筛选规则下文会讲）。
切换从节点身份：领导者哨兵向新主节点发送 SLAVEOF NO ONE 命令，使其升级为主节点；向其他从节点发送 SLAVEOF 新主节点IP 端口 命令，让它们同步新主节点的数据。
原主节点归队：当原主节点恢复后，哨兵会将其设置为新主节点的从节点，避免脑裂问题。

三、主观下线（SDOWN）与客观下线（ODOWN）：故障判断的核心逻辑

在故障转移流程中，如何准确判断主节点是否真的宕机是关键 —— 如果误判，会导致不必要的故障转移，影响系统稳定性。哨兵通过主观下线和客观下线两个阶段，来保证故障判断的准确性。

1. 主观下线（Subjectively Down，SDOWN）

定义：单个哨兵节点根据自己的监控结果，判定某个节点 “不可用” 的状态。触发条件：当一个哨兵节点向某个 Redis 节点发送 PING 命令后，在 down-after-milliseconds 配置的时间内，没有收到有效的 PONG 响应（包括超时、返回错误信息），该哨兵就会将这个节点标记为主观下线。

注意：

down-after-milliseconds 是哨兵的核心配置参数，默认 30000 毫秒（30 秒），可以根据业务需求调整。

主观下线是单个哨兵的独立判断，可能存在误判（比如网络抖动导致哨兵和节点短暂失联），因此不能直接触发故障转移。

2. 客观下线（Objectively Down，ODOWN）

定义：多个哨兵节点达成共识，一致判定主节点 “不可用” 的状态，这是触发故障转移的必要条件。触发条件：当一个哨兵节点将主节点标记为主观下线后，它会向其他哨兵节点发送询问请求：“你是否也认为主节点已经宕机？”。当超过 quorum 配置数量的哨兵节点都确认主节点为主观下线时，该主节点就会被标记为客观下线。

关键说明：

quorum 是哨兵监控主节点时的配置参数，代表 “判定主节点客观下线所需的最少哨兵数量”。

只有主节点才有客观下线状态，从节点和哨兵节点只有主观下线状态 —— 因为从节点故障不会影响集群的写服务，无需触发故障转移。

客观下线是集群共识的结果，极大降低了误判概率，只有达到这个状态，哨兵才会启动故障转移流程。

主观下线 vs 客观下线核心区别

特性	主观下线（SDOWN）	客观下线（ODOWN）
判断主体	单个哨兵节点	多个哨兵节点（集群共识）
触发对象	主节点、从节点、哨兵节点	仅主节点
触发条件	节点超时未返回 `PONG`	超过 `quorum` 数量的哨兵确认主节点 SDOWN
后续动作	无（仅本地标记）	触发领导者哨兵选举 + 故障转移
核心价值	初步检测节点异常	确保主节点故障判断的准确性

四、领导者哨兵选举机制：谁来执行故障转移？

当主节点被标记为客观下线后，哨兵集群需要选举出一个领导者哨兵，由它统一负责故障转移操作。这个选举过程遵循 Raft 算法的核心思想，保证选举的公平性和一致性。

1. 选举触发条件

主节点被判定为客观下线。
某个哨兵节点（发起者）向其他哨兵节点发送投票请求，请求成为领导者。

2. 选举核心规则

先到先得：当哨兵节点收到第一个投票请求时，会立即同意该请求，并将自己的投票权锁定（在本次选举中不再投票给其他节点）。
半数通过：发起投票的哨兵节点，只有获得超过哨兵集群半数节点的支持，才能当选为领导者哨兵。
选举超时：如果在指定时间内没有哨兵节点获得半数支持，会重新发起选举，直到选出领导者。

3. 选举的核心注意事项

哨兵集群的节点数量建议配置为奇数（3、5 等），这样可以避免 “半数” 计算的歧义，降低选举失败的概率。
领导者哨兵的唯一职责是执行故障转移，故障转移完成后，其 “领导者” 身份自动失效，下次故障时需要重新选举。

五、生产环境哨兵模式配置实战（附 sentinel.conf 关键参数解读）

理论讲完后，我们进入实战环节。以一主二从三哨兵的架构为例，讲解生产环境下的完整配置步骤，并解读 sentinel.conf 中的核心参数。

环境准备

节点类型	节点 IP	端口	角色
Redis 主节点	192.168.1.100	6379	Master
Redis 从节点 1	192.168.1.101	6380	Slave
Redis 从节点 2	192.168.1.102	6381	Slave
哨兵节点 1	192.168.1.100	26379	Sentinel
哨兵节点 2	192.168.1.101	26379	Sentinel
哨兵节点 3	192.168.1.102	26379	Sentinel

步骤 1：搭建 Redis 主从复制集群

在配置哨兵之前，需要先完成主从集群的搭建，确保从节点能同步主节点数据。

主节点配置（redis.conf）

# 绑定IP（生产环境建议绑定内网IP）
bind 192.168.1.100
# 端口
port 6379
# 守护进程运行
daemonize yes
# 日志文件
logfile "/var/log/redis/redis-6379.log"
# 数据持久化目录
dir "/data/redis/6379"
# 密码（生产环境必须配置）
requirepass "your-redis-password"
# 从节点连接主节点需要的密码
masterauth "your-redis-password"

从节点配置（redis.conf，以 6380 为例）

bind 192.168.1.101
port 6380
daemonize yes
logfile "/var/log/redis/redis-6380.log"
dir "/data/redis/6380"
requirepass "your-redis-password"
masterauth "your-redis-password"
# 关键配置：指定主节点地址和端口
slaveof 192.168.1.100 6379

启动所有主从节点，并验证主从同步状态

# 启动主节点
redis-server /etc/redis/redis-6379.conf
# 启动从节点
redis-server /etc/redis/redis-6380.conf
redis-server /etc/redis/redis-6381.conf

# 进入主节点，查看从节点状态
redis-cli -h 192.168.1.100 -p 6379 -a your-redis-password
192.168.1.100:6379> info replication
# 输出中会显示 connected_slaves:2，代表主从同步正常

步骤 2：配置哨兵节点（核心：sentinel.conf 参数解读）

所有哨兵节点的配置基本一致，我们以哨兵节点 1 为例，详细解读 sentinel.conf 的关键参数。

# 1. 基础网络配置
# 绑定哨兵节点的IP，生产环境建议绑定内网IP
bind 192.168.1.100
# 哨兵节点的端口，默认 26379，不可与 Redis 节点端口冲突
port 26379
# 守护进程运行
daemonize yes
# 哨兵日志文件路径，必须配置，否则日志会输出到控制台
logfile "/var/log/redis/sentinel-26379.log"
# 哨兵工作目录，哨兵会在该目录下生成状态文件
dir "/data/redis/sentinel-26379"

# 2. 核心监控配置（最关键！）
# 格式：sentinel monitor <集群名称> <主节点IP> <主节点端口> <quorum值>
# 含义：监控名为 mymaster 的 Redis 集群，主节点地址 192.168.1.100:6379，需要至少 2 个哨兵确认主节点下线，才触发故障转移
sentinel monitor mymaster 192.168.1.100 6379 2

# 3. 密码配置（如果 Redis 主从节点配置了密码，必须添加此参数）
sentinel auth-pass mymaster your-redis-password

# 4. 主观下线判断超时时间
# 格式：sentinel down-after-milliseconds <集群名称> <毫秒数>
# 含义：哨兵向 Redis 节点发送 PING 后，超过 30000 毫秒（30秒）未收到 PONG，标记为主观下线
# 生产建议：根据业务网络稳定性调整，网络好可设为 10000-20000，网络差可设为 30000-60000
sentinel down-after-milliseconds mymaster 30000

# 5. 故障转移超时时间
# 格式：sentinel failover-timeout <集群名称> <毫秒数>
# 含义：故障转移的总超时时间，超过此时间则认为故障转移失败，默认 180000 毫秒（3分钟）
sentinel failover-timeout mymaster 180000

# 6. 并行同步从节点数量
# 格式：sentinel parallel-syncs <集群名称> <数量>
# 含义：故障转移后，新主节点同时接受多少个从节点同步数据
# 生产建议：设为 1，避免多个从节点同时同步导致新主节点带宽被占满，影响写服务
sentinel parallel-syncs mymaster 1

# 7. 故障转移通知脚本（可选）
# 格式：sentinel notification-script <集群名称> <脚本路径>
# 含义：节点状态变化时，触发指定的脚本（可用于发送告警邮件、短信）
# sentinel notification-script mymaster /usr/local/bin/redis-alert.sh

配置注意事项：

所有哨兵节点的 sentinel monitor 配置必须一致（集群名称、主节点地址、quorum 值）。

quorum 值的设置建议：如果有 3 个哨兵节点，quorum 设为 2；如果有 5 个哨兵节点，quorum 设为 3，保证超过半数。

步骤 3：启动哨兵集群

# 启动哨兵节点（每个哨兵节点都要执行）
redis-sentinel /etc/redis/sentinel-26379.conf

# 验证哨兵是否启动成功
ps -ef | grep redis-sentinel
# 输出中会显示 redis-sentinel 进程，端口为 26379

步骤 4：验证哨兵故障转移功能

我们可以手动停止主节点，模拟主节点宕机，测试哨兵是否能自动完成故障转移。

停止主节点 Redis 进程

redis-cli -h 192.168.1.100 -p 6379 -a your-redis-password shutdown

查看哨兵日志，观察故障转移过程
```
tail -f /var/log/redis/sentinel-26379.log
```
日志中会依次出现以下关键信息：
- 标记主节点为 SDOWN → 标记为 ODOWN
- 选举领导者哨兵
- 选择最优从节点升级为主节点
- 其他从节点切换到新主节点

验证新主节点状态

# 进入任意一个从节点，查看 replication 信息
redis-cli -h 192.168.1.101 -p 6380 -a your-redis-password
192.168.1.101:6380> info replication
# 输出中 role:master，代表该节点已升级为主节点

原主节点恢复后的处理重启原主节点后，哨兵会自动将其设置为新主节点的从节点：

redis-server /etc/redis/redis-6379.conf
redis-cli -h 192.168.1.100 -p 6379 -a your-redis-password
192.168.1.100:6379> info replication
# 输出中 role:slave，master_host 为新主节点 IP