哨兵部署的六条纪律
哨兵集群能否真的顶住故障，取决于部署方式而不是配置文件写得多漂亮：数量必须是奇数才能形成多数派、必须分散在不同物理机或可用区、配置要统一模板管理、网络要双向可达、版本要与实例匹配、并且定期做故障转移演练。把这些纪律落到实处，自动切换才不是纸面能力。
基本信息
| 适用平台 | Redis 2.8+ 的 Sentinel；建议全环境版本一致 |
|---|---|
| 数量要求 | 至少 3 个，容忍 1 个故障；5 个容忍 2 个 |
| 分布要求 | 跨物理机或可用区，避免同机同时失效 |
| 配置要求 | 统一模板下发，禁止手工修改单台 |
| 演练要求 | 季度级故障转移演练并验证客户端切换 |
部署要点
- 数量为奇数：3 起，按「剩余多数派仍能选举」规划跨机房布局
- 配置统一：sentinel.conf 由模板生成，避免单台被手改后行为不一致
- 网络连通：哨兵之间、哨兵与实例之间双向可达，注意宣告地址与外网映射
- 版本一致：哨兵与 Redis 实例大版本尽量对齐，避免协议行为差异
- 演练常态化：定期触发故障转移并验证客户端是否自动重连
- 监控到位：关注主观下线与客观下线事件、切换次数、老主库残留连接
部署自检
部署自检
# 检查能否形成多数派
redis-cli -p 26379 SENTINEL ckquorum mymaster
# 列出同主库的其他哨兵，确认互相可见
redis-cli -p 26379 SENTINEL sentinels mymaster | grep -c name
# 查看被监控主库的完整信息
redis-cli -p 26379 SENTINEL masters
# 演练时手工触发一次切换（会真实改变主库）
redis-cli -p 26379 SENTINEL failover mymaster部署检查项
| 检查项 | 合格标准 | 风险 |
|---|---|---|
| 哨兵数量 | 奇数，至少 3 个 | 数量不足无法选举 |
| 部署位置 | 不同物理机或可用区 | 同机部署时一起失效 |
| 互相发现 | 每个哨兵都能看到其他哨兵 | 发现不全导致投票不足 |
| 配置管理 | 由模板统一生成 | 手工修改造成行为漂移 |
| 版本一致性 | 与实例大版本对齐 | 协议差异引发误判 |
| 演练记录 | 有定期演练与客户端验证 | 真故障时才发现流程不可用 |
在两台机器上部署 3 个哨兵（其中一台跑两个）比分散到三台更危险：那台机器一旦故障会同时失去两个投票源，仍然无法形成多数派。
把哨兵与主库部署在同一台机器：机器故障时两者一起消失，故障转移直接失去仲裁能力。