必须部署奇数个sentinel节点，因为奇数能避免网络分区时50%–50%的投票僵局，确保quorum（如3节点quorum=2、5节点quorum=3）和majority天然一致，从而可靠触发故障转移。
为什么必须部署奇数个 Sentinel 节点
奇数不是为了“好看”，而是让 Sentinel 在故障判断和故障转移时能达成多数派（quorum）投票。偶数节点在分区时容易卡在 50%–50% 的僵持状态，无法触发自动故障转移。
比如 4 个 Sentinel，网络断成两组各 2 个，双方都只能看到自己这边的主库“活着”，谁也无法凑够 quorum=3 的同意票，结果就是主库宕机后无人接管。
-
quorum是配置项，表示判定主库下线所需的最少Sentinel同意数，通常设为 ⌊n/2⌋ + 1（n 是总数） - 3 个节点：
quorum=2，允许 1 个失联仍可决策 - 5 个节点：
quorum=3，允许 2 个失联；但别盲目堆到 7+，运维成本和通信开销明显上升 - 注意：
quorum不等于“必须全部在线”，它只是最小法定人数；真正执行故障转移还需要majority（过半数）同意，所以奇数天然适配
Sentinel 配置里最容易写错的三个参数
很多脑裂问题其实源于配置没对齐，尤其是跨机器部署时手动改配置漏了某台。
-
sentinel monitor <master-name><ip><port><quorum></quorum></port></ip></master-name>：所有节点的<quorum></quorum>值必须一致，且不能大于实际节点数；<ip></ip>必须是其他Sentinel能直连的地址（别写127.0.0.1或容器内网 IP） -
sentinel down-after-milliseconds <master-name><ms></ms></master-name>：所有节点该值需相同，否则有的 Sentinel 觉得主库挂了，有的还等著，投票就乱了 -
sentinel parallel-syncs <master-name><num></num></master-name>：这个只影响从库重同步并发数，不影响高可用逻辑，但设太大可能压垮新主库，建议 ≤ 2
网络分区发生时，Sentinel 实际怎么投票和裁决
不是所有 Sentinel 同时发起投票，而是由最先发现主库异常的那个节点发起“客观下线”提议，再向其他节点发 SENTINEL is-master-down-by-addr 请求拉票。
- 只有收到 ≥
quorum个“是”的响应，才标记为主库“客观下线” - 接着进入“领导者选举”：每个
Sentinel尝试用SENTINEL failover命令自荐，靠 Raft-like 投票选出一个 Leader（要求获得 majority 票） - 如果分区导致无法凑够 majority（比如 5 节点分出 2+3），只有 3 节点那组能选出 Leader 并完成故障转移；2 节点那组既不能下线主库，也不能选 Leader，会持续报
NOGOODSLAVE或超时日志 - 分区恢复后，原主库会被降级为从库——前提是它还能连上新主库；否则需要人工介入
SENTINEL reset
验证哨兵集群是否真能扛住单点或分区故障
光看 redis-cli -p 26379 info sentinel 显示 “sentinels:3” 不代表可用，得模拟真实失效路径。
- 关掉一个
Sentinel进程，检查剩余两个是否仍能正常监控、是否还能通过SENTINEL get-master-addr-by-name拿到主库地址 - 用
iptables或network namespace隔离一个Sentinel，观察它日志里是否持续报Connection refused或timeout，另外两个是否在 30 秒内完成故障转移（取决于down-after-milliseconds） - 重点看日志关键词：
+odown（客观下线）、+new-epoch（新纪元启动）、+try-failover、+failover-end；缺任意一个环节，说明链路卡住了 - 别只测“主库宕机”，一定要测“主库活着但
Sentinel看不见它”的场景（比如主库防火墙拦了 Sentinel 端口）
脑裂不是理论风险，是配置偏差、网络抖动和时钟不同步共同触发的结果。最常被忽略的是时钟漂移——三台机器时间差超过 down-after-milliseconds 的一半，就可能导致误判。记得用 chronyd 或 ntpd 对齐时间。
