Redis 的哨兵机制是什么？

标签：后端、Redis

🏛 业务架构师

哨兵（Sentinel）是 Redis 的高可用守护体系：一组独立哨兵进程持续监控主从节点，主挂了自动完成故障转移（选举领头哨兵 → 从库中选出新主 → 其他从库改挂新主 → 通过发布订阅通知客户端新地址），同时充当客户端的服务发现入口。

业务视角，哨兵解决的是"Redis 单点故障的恢复时间"问题：

没有哨兵：主库宕机 → 人工发现（告警）→ 人工切换改配置 → 业务恢复，MTTR 以十分钟计，大促期间就是事故级停摆；
有哨兵：秒级发现（主观下线→多数哨兵仲裁客观下线，防止单个哨兵网络抖动误判）→ 自动切换 → 客户端感知（订阅 +switch-master 事件刷新连接），MTTR 压到分钟内且无需人工——高可用是买回来的业务连续性保险。

落地要点（我踩过的坑）：

哨兵至少 3 节点且奇数（仲裁多数派），与 Redis 节点分机部署——哨兵和主库同机，机器挂了哨兵也瞎了；
客户端要用哨兵感知的连接方式（Spring 配 sentinel 节点列表而非具体主地址）——写死主库地址的客户端，切换后永远连旧主；
脑裂防护必配：min-slaves-to-write——旧主被隔离时还在接受写入，切换后数据丢失。宁可写拒绝，不可双写丢数据；
应用侧配连接失败快速重试与降级（切换瞬间的秒级抖动是预期内的，业务要能扛：重试或走 DB 兜底）。

选型定位：哨兵适合单主容量够用、只需要高可用的场景（10GB 内、写 QPS 单机可扛）；容量到需要水平分片时上 Cluster——哨兵→集群的演进由容量驱动，不由技术潮流驱动。

🏗 系统架构师

哨兵（Sentinel）是 Redis 官方的高可用方案：主从复制只解决读扩展与数据冗余，主节点故障需要自动切换——哨兵就是那个独立的"裁判组"。

架构：≥3 个哨兵节点（奇数，独立部署，不与业务混部）+ Redis 主从。哨兵彼此独立，只与 Redis 和彼此通信。

三大任务：

监控：每秒 PING 主/从/其他哨兵；
裁决（主观→客观下线）：单哨兵认为主超时 = 主观下线（sdown）；询问其他哨兵，≥ quorum 个同意 = 客观下线（odown）——quorum 机制防止单点误判（网络抖动、单哨兵故障）；
自动故障转移：哨兵间投票选出 leader 哨兵执行切换：
- 从存活从库中挑选（优先级 → 复制偏移量最大（数据最全）→ runid 小）；
- 提升为新主，其余从库改挂新主；
- 旧主回来后降级为从；
- 通过发布订阅（+switch-master）通知客户端新主地址，客户端刷新连接。

生产要点：

哨兵 3/5 节点跨机架/可用区；quorum = 多数派；
脑裂防护：主配 min-replicas-to-write 1，失联时拒绝写入防丢数据；
客户端必须支持哨兵协议（Jedis/Lettuce/Redisson 均支持）；
切换有秒级窗口，业务要容忍 + 重试；
规模再大（多分片水平扩展）用 Redis Cluster，哨兵解决"一组主从"的高可用。

💻 全栈开发专家

哨兵（Sentinel）= Redis 主从架构的"自动故障转移 + 状态通知"组件，解决主库宕机需要人工切换的问题。

工作机制四步：

监控：每个哨兵每秒 PING 主/从/其他哨兵，超时无回复标记主观下线（sdown）。
仲裁：足够数量（quorum 配置）的哨兵都认为下线 → 客观下线（odown），才动手。
选举哨兵 leader：哨兵之间 Raft-like 投票选出一个执行故障转移。
故障转移：
- 挑新主：优先级 replica-priority → 复制偏移量最大（数据最全）→ runid 最小；
- 对新主发 SLAVEOF NO ONE；
- 其余从库改挂新主；
- 旧主恢复后降级为从；
- 通过发布订阅（+switch-master 频道）广播新主地址。

部署要点（我的实操配置）：至少 3 个哨兵跨节点部署（奇数，容忍挂 1 个）；客户端用哨兵模式连接（Jedis new JedisSentinelPool / Spring 配 master + sentinel 节点列表），客户端订阅事件自动切到新主。

两个必答的坑：

脑裂：主和从/哨兵网络分区时主还活着并接受写，切换后新主上位，旧主重连被清数据。防：主库配 min-replicas-to-write 1 + min-replicas-max-lag 10，从库全失联时拒绝写入。
数据丢失窗口：异步复制决定切换可能丢最后一批写，业务要幂等/可补偿，别把哨兵当零丢失方案（那是 WAIT 或共识系统的事）。