主从复制解决了数据冗余，但没有解决一个关键问题：主库挂了以后，谁来判断、谁来选新主、客户端怎么知道新地址？Sentinel 就是为这个问题而生。
Sentinel 不是一个单点裁判，而是一组特殊 Redis 进程。它们先各自判断主观下线，再通过 quorum 形成客观下线，随后选出 Leader 执行故障转移。
先把机制边界说清楚
这一篇讨论非 Cluster 模式下的自动故障转移。Sentinel 不做数据分片，也不能消除异步复制带来的丢写窗口。
整体路径
上面这张图先把主线铺开：监控、达成客观下线、选 Leader、切新主。要把故障转移讲清楚，得分清两套投票机制——quorum（判主库是否真挂）和 majority（授权谁来执行切主），两者职责不同，不能混为一谈。
底层机制
- 单个 Sentinel ping 不通主库（超过
down-after-milliseconds），会先标记主观下线（SDOWN）——这只是「我觉得它挂了」，还不算数。 - 达到
quorum后（多少个 Sentinel 同意故障，由配置决定），多个 Sentinel 对主库故障形成客观下线（ODOWN）判断。quorum 解决的是「主库到底算不算挂」。 - 这里有个必须区分的概念：quorum 和 majority 不是一回事，混淆是 Sentinel 最经典的翻车点。
quorum是「多少个 Sentinel 同意才算客观下线」；majority（半数以上 Sentinel 授权）是选 Leader 和授权故障转移必须满足的票数。也就是说：客观下线看 quorum（可以是少数派配置），但真正执行故障转移的 Leader 选举必须有多数 Sentinel（majority）授权——这是一种 Raft-like 的多数派协议，防止脑裂时多个 Sentinel 同时切主。建议 quorum 设成Sentinel 总数 / 2 + 1，让客观下线判断也过半，更稳妥。 - Leader 选出后，由它负责执行一次故障转移。
- 新主选择会考虑三个要素：
replica-priority（优先级，值小优先，0 表示永不升主）、复制进度（offset 越大越新越优先）、runid（字典序兜底）。
这些机制放在一起看，就能理解 Sentinel 为什么需要 quorum 和 majority 两套投票——前者判主库是否真挂，后者授权谁来切主，混为一谈就会误判故障转移。
取舍与边界
Sentinel 提供的是自动恢复能力，不是强一致保证。故障判断太敏感会误切，太保守又会拉长不可用时间。
典型问题：用机制化例子排查
- 至少部署 3 个 Sentinel，并跨故障域放置。
- 客户端必须使用 Sentinel 感知新主，不能写死 master 地址。
- 合理配置 down-after-milliseconds、quorum 和 failover-timeout。
- 故障演练要覆盖主库宕机、网络隔离和从库延迟三种场景。
收束：一句判断
Sentinel 的价值，是把人工切主变成一套可观测、可演练的流程。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
