主从复制解决了数据冗余，但没有解决一个关键问题：主库挂了以后，谁来判断、谁来选新主、客户端怎么知道新地址？Sentinel 就是为这个问题而生。
Sentinel 不是一个单点裁判，而是一组特殊 Redis 进程。它们先各自判断主观下线，再通过 quorum 形成客观下线，随后选出 Leader 执行故障转移。
先把机制边界说清楚
这一篇讨论非 Cluster 模式下的自动故障转移。Sentinel 不做数据分片，也不能消除异步复制带来的丢写窗口。
整体路径
上面这张图先把主线铺开：监控、达成客观下线、选 Leader、切新主。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
- 单个 Sentinel ping 不通主库，会先标记主观下线。
- 达到 quorum 后，多个 Sentinel 对主库故障形成客观下线判断。
- Sentinel 之间选出 Leader，由 Leader 负责一次故障转移。
- 新主选择会考虑优先级、复制进度和运行状态。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
Sentinel 提供的是自动恢复能力，不是强一致保证。故障判断太敏感会误切，太保守又会拉长不可用时间。
典型问题：用机制化例子排查
- 至少部署 3 个 Sentinel，并跨故障域放置。
- 客户端必须使用 Sentinel 感知新主，不能写死 master 地址。
- 合理配置 down-after-milliseconds、quorum 和 failover-timeout。
- 故障演练要覆盖主库宕机、网络隔离和从库延迟三种场景。
收束：一句判断
Sentinel 的价值，是把人工切主变成一套可观测、可演练的流程。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
