Redis Sentinel的仲裁机制由quorum和majority协同实现：quorum决定客观下线（ODOWN）阈值，majority确保故障转移需多数哨兵在线参与选举，二者共同保障自动、可靠、防脑裂的高可用切换。
Redis Sentinel 的集群仲裁机制不是“手动配置”的功能，而是由哨兵节点间通过分布式共识自动触发的逻辑过程。核心在于两个关键参数协同作用：quorum 和 majority，它们共同决定故障是否被确认、以及能否执行故障转移。
quorum 参数：触发客观下线的最小同意数
它定义的是：当多少个 Sentinel 同意 master “主观下线”（SDOWN）后，该 master 就会被标记为“客观下线”（ODOWN）。这个值在 sentinel monitor 指令中指定：
-
语法示例：
sentinel monitor mymaster 127.0.0.1 6379 2→ 表示至少 2 个 Sentinel 认为 master 不可达，才进入 ODOWN 状态 - quorum 可设为任意正整数，但不能大于哨兵总数；通常建议设为 ⌊N/2⌋ + 1（N 为哨兵数），例如 3 个哨兵设为 2，5 个哨兵设为 3
- 注意：quorum 只影响“是否判定为客观下线”，不决定能否执行切换
majority（多数派）：执行故障转移的法定人数
即使 master 被判为 ODOWN，真正发起故障转移还需满足“多数哨兵在线并参与选举”。这个 majority 是自动计算的：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 3 个哨兵 → majority = 2
- 4 或 5 个哨兵 → majority = 3
- 6 或 7 个哨兵 → majority = 4
- 公式：majority = ⌊N/2⌋ + 1（向上取整的多数）
- 只有存活且能通信的哨兵数量 ≥ majority，才能选出 leader 并执行 failover；否则切换被阻塞
哨兵数量与部署建议
仲裁可靠性直接取决于哨兵节点数和部署方式：
- 必须 ≥ 3 个哨兵实例，避免脑裂或单点误判；2 个哨兵存在“多数不可达”风险（majority=2，挂掉 1 个就无法切换）
- 推荐奇数个（3 / 5 / 7），便于投票达成明确多数，减少平票可能
- 哨兵应跨物理机或可用区部署，避免同机宕机导致多个哨兵同时失联
- 每个哨兵需能独立访问所有 Redis 节点（master + slaves），网络连通性是仲裁前提
故障转移时的实际仲裁流程
当 master 失联后，哨兵集群按以下步骤完成仲裁：
- 各哨兵先各自判断 master 是否 SDOWN（超时未响应）
- 互相交换状态，若 ≥ quorum 个哨兵报告 SDOWN，则标记为 ODOWN
- 存活哨兵数 ≥ majority 的组，启动 leader 选举：通过 Raft-like 投票（每个哨兵投一票），得票过半者成为 leader
- leader 从 slaves 中挑选一个（依据优先级、复制偏移量、runid 等规则）提升为新 master，并通知其余 slaves 切换主从关系
- 整个过程无需人工干预，但依赖哨兵间通信正常、时间同步准确（建议 NTP）
