哨兵选主按slave-priority、复制偏移量、RunID三步筛选：优先过滤priority为0的节点；再比对offset，越大越优；最后按RunID字典序升序取首个。
哨兵选主时，slave-priority 是第一道筛选门槛
不是所有从节点都有资格被选为主节点。哨兵启动选举前，会先过滤掉 slave-priority 设为 0 的从节点——这类节点被显式标记为“禁止晋升”，哪怕它数据最新、延迟最低，也会直接跳过。
实操建议：
-
slave-priority值越小，优先级越高；默认是 100，设为 10 表示比默认节点更可能当选 - 不要在生产环境把多个节点都设成 0，否则可能触发“无合格候选者”，导致故障期间无法自动恢复
- 修改后需执行
CONFIG REWRITE或重启 Redis，仅CONFIG SET不会持久化到配置文件
复制偏移量（offset）决定谁能进决赛圈
过了 slave-priority 这关的节点，哨兵会比对它们的复制偏移量（即 master_repl_offset）。偏移量越大，说明该从节点同步得越完整，离主节点的数据断层越小。
常见错误现象：某从节点网络短暂抖动后恢复，但没来得及追上主节点的新写入，它的 offset 就落后了——这种节点即使在线、健康，也会在第二轮被淘汰。
注意点：
- 偏移量比较基于哨兵最后一次向各从节点发送
INFO replication获取的值，不是实时值 - 如果多个节点偏移量完全相同，哨兵不会随机挑，而是进入下一轮比拼
- 别指望靠调大
repl-backlog-size来“保偏移量”——它只影响断连重连后的部分同步，不影响选举逻辑
RunID 是最终裁决者，但它的排序不等于“越小越好”
当多个从节点的 slave-priority 和 offset 都一致时，哨兵用 RunID 做最终选择。这里不是字典序比大小，而是按 RunID 字符串做字典序升序排列，取第一个。
这意味着：
- RunID 是实例启动时生成的随机字符串（如
758a9b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a），不可预测也不可配置 - 你无法通过控制 RunID 来干预选主结果，强行重启某个从节点来“刷出好 RunID”没有意义
- 真正可控的是前两步：确保关键从节点
slave-priority合理、网络稳定以维持高offset
手动故障转移时，SENTINEL failover 不绕过上述规则
有人以为执行 SENTINEL failover <master-name></master-name> 就能指定某个从节点上位，其实不然。这个命令只是强制触发一次选举，所有筛选逻辑照旧：优先级 → 偏移量 → RunID。
如果你发现执行后没选中预期节点，大概率是：
- 目标节点
slave-priority被设成了 0，或比其他节点低 - 它的
offset确实落后（可用INFO replication对比确认） - 你误以为它“最近重启过所以更新”，但实际同步延迟未消除
真正想锁定某个节点上位，只能临时调高它的 slave-priority，等哨兵刷新状态后再执行 SENTINEL failover。
RunID 看似是兜底规则，但它暴露了一个事实：哨兵不维护节点“资历”或“稳定性历史”，只看当下可采集的三个硬指标。很多线上问题，其实是前两个环节悄悄掉了链子，最后才在 RunID 上“意外翻车”。
