Sentinel哨兵机制
Redis Sentinel 用于监控主从实例、判断主观/客观下线、选举新主并通知客户端。它解决的是主从架构下的自动故障切换问题，而不是数据分片问题。
# 1. 学习定位
| 维度 | 内容 |
|---|---|
| 难度层级 | 高可用基础 |
| 核心目标 | 先会用，再理解机制，最后能做工程取舍和故障分析 |
| 学习方法 | 带着业务场景看命令、SQL、数据结构、日志和运行时指标 |
# 2. 核心地图
Sentinel哨兵机制
├─ 监控
├─ 主观下线
├─ 客观下线
├─ 领导者选举
├─ 故障转移
├─ 配置纪元
└─ 客户端发现
# 3. 小章节深度讲解
下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。
# 3.1. 监控
# 是什么
监控 属于 Redis 可观测性。Redis 故障可能来自命令、内存、网络、复制、持久化、客户端或操作系统，需要指标分层定位。
# 开发人员怎么用
开发人员要记录 Redis 调用耗时、超时、重试、降级和业务 key。没有应用侧 trace，就很难区分客户端排队和服务端慢命令。
# 运维人员怎么看
运维人员要建立包含 QPS、P99、slowlog、内存、碎片率、连接、复制延迟、持久化状态和 keyspace 的面板。故障排查要按时间线推进。
# 常见风险
常见风险是生产高峰开启 MONITOR 或只看平均延迟。Redis 事故往往是短时尖刺，必须看尾延迟和事件。
# 3.2. 主观下线
# 是什么
主观下线 属于 Redis 高可用和运行时协调。它影响故障检测速度、切换正确性、复制延迟和客户端重连表现。
# 开发人员怎么用
开发人员要处理短暂不可用、读旧数据、连接重建和请求重试。客户端必须支持 Sentinel 或 Cluster 的发现协议。
# 运维人员怎么看
运维人员要设置合理 quorum、超时、复制 backlog 和告警阈值，并演练主库故障、网络分区和客户端重连。
# 常见风险
常见风险是 Sentinel 判断切换成功，但客户端仍缓存旧地址；或者后台任务、复制和持久化延迟叠加，导致业务侧误判 Redis 已不可用。
# 3.3. 客观下线
# 是什么
客观下线 属于 Redis 高可用和运行时协调。它影响故障检测速度、切换正确性、复制延迟和客户端重连表现。
# 开发人员怎么用
开发人员要处理短暂不可用、读旧数据、连接重建和请求重试。客户端必须支持 Sentinel 或 Cluster 的发现协议。
# 运维人员怎么看
运维人员要设置合理 quorum、超时、复制 backlog 和告警阈值，并演练主库故障、网络分区和客户端重连。
# 常见风险
常见风险是 Sentinel 判断切换成功，但客户端仍缓存旧地址；或者后台任务、复制和持久化延迟叠加，导致业务侧误判 Redis 已不可用。
# 3.4. 领导者选举
# 是什么
领导者选举 属于 Redis 高可用和运行时协调。它影响故障检测速度、切换正确性、复制延迟和客户端重连表现。
# 开发人员怎么用
开发人员要处理短暂不可用、读旧数据、连接重建和请求重试。客户端必须支持 Sentinel 或 Cluster 的发现协议。
# 运维人员怎么看
运维人员要设置合理 quorum、超时、复制 backlog 和告警阈值，并演练主库故障、网络分区和客户端重连。
# 常见风险
常见风险是 Sentinel 判断切换成功，但客户端仍缓存旧地址；或者后台任务、复制和持久化延迟叠加，导致业务侧误判 Redis 已不可用。
# 3.5. 故障转移
# 是什么
故障转移 属于 Redis 高可用或集群拓扑。它决定数据如何复制、故障时如何提升新主、客户端如何找到正确节点。
# 开发人员怎么用
开发人员要选择支持 Sentinel 或 Cluster 的客户端，并处理读旧数据、重定向、拓扑刷新和跨槽限制。
# 运维人员怎么看
运维人员要监控复制延迟、offset 差距、backlog 命中、Sentinel quorum、槽迁移和每个分片的内存/QPS/延迟。
# 常见风险
常见风险是只看集群总容量，忽略单槽热点、单 key 热点和客户端不支持重定向。
# 3.6. 配置纪元
# 是什么
配置纪元 属于 Redis 高可用和运行时协调。它影响故障检测速度、切换正确性、复制延迟和客户端重连表现。
# 开发人员怎么用
开发人员要处理短暂不可用、读旧数据、连接重建和请求重试。客户端必须支持 Sentinel 或 Cluster 的发现协议。
# 运维人员怎么看
运维人员要设置合理 quorum、超时、复制 backlog 和告警阈值，并演练主库故障、网络分区和客户端重连。
# 常见风险
常见风险是 Sentinel 判断切换成功，但客户端仍缓存旧地址；或者后台任务、复制和持久化延迟叠加，导致业务侧误判 Redis 已不可用。
# 3.7. 客户端发现
# 是什么
客户端发现 属于 Redis 高可用和运行时协调。它影响故障检测速度、切换正确性、复制延迟和客户端重连表现。
# 开发人员怎么用
开发人员要处理短暂不可用、读旧数据、连接重建和请求重试。客户端必须支持 Sentinel 或 Cluster 的发现协议。
# 运维人员怎么看
运维人员要设置合理 quorum、超时、复制 backlog 和告警阈值，并演练主库故障、网络分区和客户端重连。
# 常见风险
常见风险是 Sentinel 判断切换成功，但客户端仍缓存旧地址；或者后台任务、复制和持久化延迟叠加，导致业务侧误判 Redis 已不可用。
# 3.8. 本篇学习实验
建议准备一个独立 Redis 实例，构造小 key、大 key、热点 key、过期 key 和慢命令，观察 INFO、SLOWLOG、LATENCY、内存变化和客户端超时。每个实验都要记录命令复杂度和返回数据量。
开发侧实验重点是理解数据结构和命令边界，运维侧实验重点是理解延迟、内存和复制如何变化。真正掌握本篇内容，应该能从延迟尖刺反推大 key、慢命令、持久化或网络问题。
# 4. 核心机制
- Sentinel 定期向主从和其他 Sentinel 发送探测，判断实例是否可达。
- 单个 Sentinel 认为主库不可达是主观下线，多数 Sentinel 达成一致后是客观下线。
- 故障转移会从从节点中选择合适节点提升为新主，并让其他从节点复制新主。
- 客户端需要支持 Sentinel 协议，以便主节点变化后重新发现写入口。
# 5. 工程实践
- Sentinel 至少部署奇数个独立节点，避免与 Redis 主从完全同故障域。
- 设置合理 down-after、failover-timeout 和 quorum，平衡切换速度与误判风险。
- 定期演练主库故障、网络分区和客户端重连。
- 业务写入要有超时、重试和幂等，切换期间可能短暂失败。
# 6. 常见坑
- Sentinel 和 Redis 部署在同一台机器，机器故障时一起消失。
- quorum 设置不合理，导致无法切换或误切换。
- 客户端不支持 Sentinel，切换后仍写旧主。
- 把 Sentinel 当成 Cluster，以为可以自动分片。
# 7. 专家视角
- Sentinel 解决可用性，不解决容量分片。
- 专家会关注脑裂风险、旧主恢复处理和客户端发现机制。
- 自动切换必须配合监控和人工兜底，不能只相信默认配置。
# 8. Tips 快问快答
Q：Sentinel 能分片吗？
A：不能。它负责主从高可用，不负责数据分片。
Q：为什么需要多个 Sentinel？
A：为了多数派判断和避免单点误判。
Q：切换期间写请求会怎样？
A：可能短暂失败或超时，应用要有重试和幂等。
# 9. 阶段小结
Sentinel哨兵机制 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。