一、前言：哨兵如何“知道”主节点挂了？
在 Redis 哨兵（Sentinel）高可用架构中，自动故障转移的前提是准确、及时地发现节点故障。
但网络抖动、GC 暂停、机器假死等场景，使得“判断一个节点是否真的宕机”变得异常复杂。
哨兵集群的监控机制，正是通过多层检测 + 分布式共识，来避免误判与漏判。
本文将深入剖析：
✅ 哨兵如何监控 Redis 节点？
✅ Sentinel 之间如何通信并达成共识？
✅ 主观下线（SDOWN） 与 客观下线（ODOWN） 的判定逻辑
✅ 监控相关的配置参数与调优建议
二、哨兵监控的三层架构
哨兵的监控能力分为两个维度：
维度 1：对 Redis 节点的监控（纵向）
- 监控 主节点（Master） 和 从节点（Slave） 的健康状态
维度 2：Sentinel 节点间的协同（横向）
- 通过 Gossip 协议 同步彼此的观测结果，形成集群共识
✅ 核心思想：单点观测不可靠，集群共识才可信。
三、第一层：哨兵对 Redis 节点的心跳检测
每个 Sentinel 实例会独立、周期性地向所有 Redis 节点（主+从）发送心跳命令。
3.1 心跳命令
- 主要使用 PING 命令（每秒 1 次）
- 也会定期执行 INFO（获取主从拓扑）、ROLE（确认角色）
3.2 主观下线（Subjectively Down, SDOWN）
- 定义：单个 Sentinel 认为某 Redis 节点不可达
- 判定条件：
sentinel down-after-milliseconds <master-name> 30000
- 若连续 30000 毫秒（30秒）未收到有效响应，则标记为 SDOWN
⚠️ 注意：
- SDOWN 是本地状态，不通知其他 Sentinel
- 不会触发故障转移！
3.3 监控对象包括
| 主节点 | 可写性、响应延迟 |
| 从节点 | 复制延迟（lag）、连接状态 |
| 其他 Sentinel | 是否存活（用于 Gossip） |
四、第二层：Sentinel 之间的 Gossip 通信
为了将“主观判断”升级为“客观事实”，Sentinel 节点之间通过 Gossip 协议 交换信息。
4.1 通信方式
- 端口：默认 26379
- 协议：基于 Redis 协议的自定义消息
- 频率：每 2 秒向其他 Sentinel 发送一次 PING（含自身观测状态）
4.2 交换的信息包括
- 自己监控的主节点是否 SDOWN
- 从节点列表及状态
- 当前主节点的 runid 和 offset
- 其他 Sentinel 的存活状态
4.3 Gossip 的优势
- 去中心化：无主节点，任意节点可发起通信
- 最终一致性：信息在集群内快速扩散
- 容错性强：部分节点失联不影响整体判断
五、第三层：客观下线（ODOWN）与故障共识
当多个 Sentinel 对同一主节点达成“它已宕机”的共识时，才会触发故障转移。
5.1 客观下线（Objectively Down, ODOWN）
- 定义：集群中有 ≥ quorum 个 Sentinel 认为主节点 SDOWN
- 判定公式：
ODOWN = (SDOWN 的 Sentinel 数量 ≥ quorum)
# sentinel.conf
sentinel monitor mymaster 192.168.1.100 6379 2
# ↑
# quorum = 2
🔑 关键点：
- quorum 不是多数派，而是 ODOWN 的门槛值
- 但后续 Leader 选举仍需多数派（> N/2）
5.2 举例说明
| 3 | 2 | 2 | 1 |
| 5 | 3 | 3 | 2 |
✅ 生产建议：3 节点 + quorum=2，平衡安全性与可用性
六、监控流程完整示例
假设主节点 M1 因宕机停止响应：
- SDOWN 数量 = 2 ≥ quorum(2) → 标记 ODOWN
⏱️ 整个过程通常在 30~60 秒内完成
七、关键监控配置参数详解
| down-after-milliseconds | 30000 ms | 判定 SDOWN 的超时时间 | 网络稳定可设 10~20s；跨机房可设 60s |
| quorum | — | ODOWN 所需 Sentinel 数量 | 3 节点设 2，5 节点设 3 |
| parallel-syncs | 1 | 故障转移后，并行同步从节点数 | 提高可加速恢复，但增加主节点压力 |
| failover-timeout | 180000 ms | 故障转移总超时 | 应 > 整个切换流程时间 |
💡 注意：down-after-milliseconds 过小 → 误判（网络抖动）；过大 → 恢复慢
八、如何监控哨兵自身的健康状态？
8.1 查看 Sentinel 状态
redis-cli -p 26379 SENTINEL MASTER mymaster
关键字段：
- flags: s_down, o_down, master
- num-slaves: 从节点数量
- num-other-sentinels: 其他 Sentinel 数量
8.2 日志监控（重点关注）
+sdown master mymaster 192.168.1.100 6379 # 主观下线
+odown master mymaster 192.168.1.100 6379 # 客观下线
+switch-master mymaster … # 主从切换
8.3 Prometheus 指标（通过 redis_exporter）
- redis_sentinel_masters
- redis_sentinel_slaves
- redis_sentinel_sentinels
- redis_sentinel_master_status（0=ODOWN, 1=OK）
九、常见监控陷阱与避坑指南
❌ 陷阱 1：只监控主节点，忽略从节点 lag
后果：从节点数据严重落后，切换后数据丢失
方案：监控 slave0:lag（来自 INFO REPLICATION）
❌ 陷阱 2：quorum 设置不合理
- 3 节点设 quorum=3 → 任一 Sentinel 宕机，无法 ODOWN
- 5 节点设 quorum=1 → 易误判
建议：quorum = floor(N/2) + 1
❌ 陷阱 3：Sentinel 与 Redis 混部
后果：Redis OOM 或 CPU 打满，导致 Sentinel 也无法工作
方案：Sentinel 独立部署，资源隔离
十、结语
感谢您的阅读！如果你有任何疑问或想要分享的经验，请在评论区留言交流！
