replica-priority需分层配置，结合数据新鲜度、网络稳定性与角色定位；必须配在从节点redis.conf中，设0即弃权参选，优先级仅是选举第一轮筛选，复制偏移量才是关键。
从节点优先级不是“设得越低越好”，而是要结合数据新鲜度、网络稳定性、角色定位来分层配置；盲目统一设为 10 或 0，反而容易导致故障转移失败或选出次优节点。
replica-priority 必须配在从节点自己的 redis.conf 里
这个值只对从节点生效，主节点配置了也无效。常见错误是改了 sentinel.conf 或主节点的 redis.conf，结果哨兵完全读不到。比如你有三台机器：6379（主）、6380（从A）、6381（从B），想让 6380 优先当选，就必须编辑 /etc/redis/6380.conf，加入一行：replica-priority 20。改完别忘了验证：redis-cli -p 6380 CONFIG GET replica-priority，返回 "20" 才算落地。
设成 0 不代表“安全”，而是主动弃权参选
当某个从节点只用于离线分析、冷备、或资源严重受限时，可以设 replica-priority 0。但它一旦被设为 0，哪怕数据最新、延迟为 0、运行最稳，哨兵也会直接跳过它。更危险的是：如果其他从节点因网络抖动、复制中断或主观下线被过滤，而唯一健康节点又设了 0，哨兵会卡在“no suitable slave to promote”——故障转移彻底失败。生产环境建议至少保留一个节点不设 0，且确保它复制链路稳定。
优先级只是第一轮筛选，真正决定谁上位的是复制偏移量
哨兵选举是三步流水线：
– 第一步按 replica-priority 升序排候选节点；
– 第二步比 slave_repl_offset，谁离原主的数据差得越少，谁越靠前；
– 第三步才比 runid 字典序（不可控）。
所以即使 A 节点设了 replica-priority 10，B 设了 100，但 A 的 offset 比 B 少 50MB，B 仍会胜出。这意味着：光调参数没用，必须盯住 INFO replication 里的 master_link_status:up 和 lag 值，确保低延迟复制正常运行。
多从节点场景下建议做差异化配置
不要所有从节点都设相同值。例如一主两从架构中：
– 把网络质量好、与主节点同机房、带宽充足的从节点设为 replica-priority 10；
– 把跨机房、仅用于灾备、偶尔同步的从节点设为 replica-priority 50；
– 把纯只读分析、不参与服务的节点设为 replica-priority 0。
这样既保留弹性，又避免所有节点挤在同一个优先级导致第二轮比 offset 时出现随机性。真正的复杂点从来不在配置语法，而在复制链路是否真实健康——它不写在 conf 里，只反映在 redis-cli -p 6380 INFO replication 的实时输出中。
