replica-priority 必须配置在从节点 redis.conf 中且格式为“replica-priority 10”，仅 Redis 5.0+ 有效；设为0表示弃权参选，但需确保至少一个健康从节点 priority > 0；最终主节点选举还取决于复制偏移量等运行态指标。
replica-priority 必须写在从节点 redis.conf 里
这个参数只对从节点生效，主节点和哨兵节点的配置文件里写它完全无效。常见错误是把 replica-priority 10 塞进 sentinel.conf 或主节点的 redis.conf，结果故障转移时发现没起作用。
正确做法是：找到你要设优先级的那个从节点对应的配置文件，比如端口是 6380，就去改 /etc/redis/6380.conf（路径以你实际部署为准），在文件末尾加一行：
replica-priority 10
注意：replica-priority 是 Redis 5.0+ 的名字，旧版用 slave-priority；但如果你用的是 5.0+ 却写了 slave-priority，Redis 不报错，只是默默忽略——它压根不读这个键。
语法和验证不能跳过
写错格式等于白配。以下写法全部无效：
-
replica-priority = 10（等号多余） -
replica-priority "10"（引号多余） -
replica-priority: 10（冒号多余）
必须严格是空格分隔的纯数字：replica-priority 10
改完别急着测试故障，先验证是否落地：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -p 6380 CONFIG GET replica-priority
返回类似 1) "replica-priority" 2) "10" 才算真正生效。如果返回 "100"，说明配置没加载，大概率是路径错了、没重启、或写进了错误的配置文件。
设为 0 就彻底弃权，但要小心单点风险
replica-priority 0 表示“我拒绝参选”，哪怕它数据最新、网络最稳，哨兵也会跳过它。适合冷备节点或只读分析从库。
但生产环境里，如果只有一个健康从节点，又把它设成了 0，而其他从节点全挂了或同步延迟严重，故障转移会直接失败——哨兵日志里会出现 no suitable replica 或反复重试超时。
所以设 0 前必须确认：至少还有一个 replica-priority > 0 的健康从节点在线，且 INFO replication 中 master_link_status:up、lag 接近 0。
priority 只是第一关，复制偏移量才是决定性因素
哨兵选新主是四层漏斗：
- 第一层筛掉断连、主观下线、INFO 失败的节点
- 第二层按
replica-priority升序排序 - 第三层比
slave_repl_offset：谁离原主的数据最新，谁胜出 - 第四层才看
run_id字典序
也就是说，即使 A 节点 replica-priority 10，B 是 50，但如果 A 的 offset 比 B 少 200MB，B 依然当选。真正影响结果的，往往是网络抖动、复制积压、backlog 大小这些运行态指标，而不是配置本身。
