Redis哨兵建议配置奇数个，以避免ODOWN判定平票、确保Leader选举唯一性，并支持跨机房高可用；quorum应设为⌊N/2⌋+1，兼顾容错与安全性。
Redis 哨兵节点建议配置为奇数个，核心是为了保障故障判定和故障转移过程中的决策一致性，避免因投票平局导致系统卡死或脑裂。
防止 ODOWN 判定出现平票僵局
哨兵通过“多数派协议”判断主节点是否客观下线（ODOWN），要求至少 quorum ≥ N/2 + 1 个哨兵达成一致。这个 quorum 不是简单“过半”，而是明确的最小同意数：
- 3 个哨兵 → quorum = 2（2 票同意即可触发故障转移）
- 4 个哨兵 → quorum 至少为 3，但若 2 个哨兵失联，剩下 2 个无法凑够 3 票；更危险的是，网络分区时可能刚好各 2 票，判定结果冲突，无法推进
- 5 个哨兵 → quorum = 3，允许最多 2 个哨兵失效仍能正常决策
偶数节点天然存在“对半分裂”风险，而奇数节点在任意单点或单机房故障后，剩余节点数更大概率仍能满足 quorum 要求。
确保领导者选举顺利达成
故障转移需由一个“领头哨兵”（Leader Sentinel）执行，其选举采用类似 Raft 的投票机制：
- 每个参与选举的哨兵给自己投一票，并向其他哨兵发起拉票
- 只有获得 ≥ quorum 票且超过半数的哨兵，才能成为有效 Leader
- 3 哨兵时，2 票即满足条件；4 哨兵时，若设定 quorum=2，则可能出现两个哨兵各自得 2 票，形成双 Leader 竞争，引发脑裂
奇数配置从结构上消除了严格平票的可能性，降低选举失败或并发操作风险。
支撑跨机房高可用部署
生产环境通常将哨兵分散部署在多个机房。若总数为奇数（如 3 或 5），可做到：
- 每个机房至少部署 1 个哨兵
- 任意单个机房整体断网后，其余机房的哨兵数量仍 ≥ quorum（例如 3 机房各 1 个，坏掉 1 个还剩 2 个，刚好满足 quorum=2）
- 若用 4 个哨兵并分在 2 个机房（2+2），一旦任一机房断网，剩余 2 个无法达到 quorum=3，故障转移将被阻塞，返回 NOQUORUM 错误
quorum 配置必须与哨兵总数匹配
配置项 sentinel monitor mymaster ip port quorum 中的 quorum 值不能随意设置：
- 必须 ≤ 实际哨兵总数
- 推荐设为 (N / 2) + 1（N 为哨兵总数，向下取整后加 1），例如 N=3 → quorum=2；N=5 → quorum=3
- 设得过高（如 5 哨兵配 quorum=5），则只要一个哨兵宕机就无法触发转移；设得过低（如 5 哨兵配 quorum=1），单个哨兵误判就可能错误切换主库
