4. 哨兵模式概述：哨兵（Sentinel）的作用、核心功能
在 Redis 主从复制架构中，当主节点（Master）发生故障时，需要人工介入进行主从切换，这会导致服务中断。Redis Sentinel（哨兵）正是为解决这一问题而设计的分布式高可用解决方案。它通过监控、通知和自动故障转移三大核心功能，实现了无需人工干预的自动故障恢复。
4.1 哨兵（Sentinel）的作用
Sentinel 本质上是一个运行在特殊模式下的 Redis 服务器进程。它的核心作用是作为整个 Redis 集群的“守护者”，持续监控主节点和从节点的健康状态，并在主节点不可用时自动完成故障转移，将某个从节点提升为新的主节点，从而保证服务的持续可用性。
关键特性： Sentinel 本身也是一个分布式系统，通常部署奇数个（至少 3 个）Sentinel 节点组成哨兵集群，通过 Raft 协议 达成共识，避免单点故障和“脑裂”问题。
4.2 核心功能详解
Sentinel 的核心功能可以归纳为以下三个维度：
| 核心功能 | 功能描述 | 关键技术点 |
|---|---|---|
| 监控（Monitoring） | 持续检查主节点和从节点是否正常运行，包括网络可达性、进程存活状态等。 | 定期发送 PING/PONG 命令；主观下线（SDOWN）与客观下线（ODOWN）判定。 |
| 通知（Notification） | 当被监控的 Redis 实例发生异常时，Sentinel 可以通过 API 或脚本向系统管理员或其他应用程序发送告警。 | 支持自定义通知脚本；可通过 Pub/Sub 发布状态变更事件。 |
| 自动故障转移（Automatic Failover） | 当主节点被判定为客观下线后，Sentinel 集群自动选举一个从节点升级为新的主节点，并更新其他从节点的复制目标。 | 领导者选举、从节点筛选、配置重写、客户端重定向。 |
4.3 哨兵架构与故障转移流程
下图展示了 Sentinel 集群的典型部署架构以及自动故障转移的核心流程：
4.4 主观下线与客观下线
Sentinel 的故障判定分为两个阶段，这是避免误判的关键机制：
- 主观下线（SDOWN - Subjectively Down）： 单个 Sentinel 节点在指定时间（
down-after-milliseconds）内未收到目标实例的有效回复，则将该实例标记为主观下线。 - 客观下线（ODOWN - Objectively Down）： 仅针对主节点。当多个 Sentinel（数量超过
quorum配置值）都认为某个主节点主观下线时，该主节点被判定为客观下线，从而触发自动故障转移。
最佳实践： 建议将
quorum 设置为 Sentinel 节点总数的一半以上（例如 3 个 Sentinel 节点时设置 quorum=2），以确保故障判定具备多数派共识，防止网络分区导致的误切换。
4.5 自动故障转移详细步骤
当主节点被判定为客观下线后，Sentinel 集群会执行以下步骤完成故障转移：
- 领导者选举： Sentinel 集群使用 Raft 协议选举出一个领导者（Leader Sentinel），由它负责执行故障转移操作。
- 从节点筛选： 领导者从健康的从节点中，根据优先级（
slave-priority）、数据复制偏移量、运行 ID 等条件，选出一个最优从节点作为新主节点。 - 执行
slaveof no one： 领导者向选中的从节点发送slaveof no one命令，使其停止复制并升级为新的主节点。 - 更新配置： 领导者向其他从节点发送
slaveof命令，让它们开始复制新的主节点。 - 配置重写： 当原主节点恢复后，Sentinel 会将其降级为从节点，并更新其配置，使其复制新的主节点。
4.6 通知机制
Sentinel 的通知功能不仅限于故障转移，它还可以在以下场景触发通知：
| 通知类型 | 触发条件 | 典型用途 |
|---|---|---|
| +sdown | 实例被标记为主观下线 | 触发运维人员关注 |
| -sdown | 实例从主观下线恢复 | 确认问题已自动恢复 |
| +odown | 主节点被标记为客观下线 | 即将触发故障转移 |
| +switch-master | 故障转移完成，主节点切换 | 通知客户端更新连接信息 |
| +slave | 新的从节点加入 | 拓扑变更记录 |
注意事项： Sentinel 的通知机制依赖于 Pub/Sub 频道（如
__sentinel__:hello）和可选的 通知脚本。在生产环境中，建议将通知与监控系统（如 Prometheus Alertmanager、Zabbix）集成，实现自动化告警。