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）