replica-priority仅在哨兵故障转移选举新主时起作用，数值越小优先级越高，0表示不参与选举；它需经四层过滤（健康检查、replica-priority、slave_repl_offset、run_id）才生效，且修改后须执行SENTINEL RECONFIGURE或重启哨兵才能生效。
replica-priority 参数只在故障转移时起作用
这个值不会影响日常复制行为，也不会让从节点“更努力地同步”，它纯粹是哨兵选举新主时的排序依据之一。当多个从节点都健康、同步进度相近时，replica-priority 才会成为决定性因素。
数值越小优先级越高，0 表示不参与选举
默认值是 100，你设成 90 就比默认高，设成 10 就更高；但设成 0 会让该从节点彻底退出候选池——哪怕它数据最新、网络最稳，哨兵也会跳过它。生产环境里常把某台从节点（比如跨机房部署的）设为 0，避免因网络抖动误选。
必须配合其他筛选条件一起看
哨兵选主不是只看 replica-priority，而是四层过滤：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先剔除主观下线、断连、没响应 PING 的从节点
- 再按
replica-priority排序（相同则进入下一层） - 接着比
slave_repl_offset（复制偏移量），越大说明数据越新 - 最后用
run_id字典序定胜负（纯兜底，避免并列）
所以光调低 replica-priority 不够，还得确保该节点网络稳定、复制延迟低，否则它根本进不了第二轮。
配置后必须重启哨兵或用 SENTINEL RECONFIGURE 生效
改完 Redis 配置里的 replica-priority，仅重启 Redis 实例无效；哨兵进程需要重新加载拓扑信息。有两种方式：
- 重启所有哨兵进程（简单粗暴）
- 对任意一个哨兵执行
SENTINEL RECONFIGURE <master-name>（推荐，热生效）
注意：SENTINEL RECONFIGURE 不会重载整个配置文件，只刷新该主节点下的从节点状态，所以改了 replica-priority 后必须触发它，否则哨兵仍按旧值判断。
replica-priority 设得再合理，如果哨兵没收到更新，它就永远不知道这个变化。 
