应检查主从节点的复制偏移量（master_repl_offset与slave_repl_offset）是否持续增长且差值稳定，同时确认从节点master_link_status为up、master_sync_in_progress为0，并排除认证失败、min-replicas-to-write限制及客户端拓扑缓存过期等问题。
如何确认从节点是否真的在复制（而不仅是“在线”）
“Slave nodes are not participating”不是 Redis 原生错误字符串，而是运维侧对 cluster nodes 中出现 slave,noaddr、slave,disconnected 或 slave 但 offset 长期不更新等现象的概括性描述。它本质反映：从节点虽注册进集群，但未真正参与数据同步。不能只看 cluster nodes 输出里有没有 slave 字样，必须验证复制链路是否活。
- 用
redis-cli -h <master-ip> -p <master-port> info replication</master-port></master-ip>查主节点的slave0（或slave1）字段，确认offset是否在增长；静止不动说明复制卡住 - 登录从节点，执行
info replication，检查master_link_status:up和master_sync_in_progress:0—— 若为down或1持续很久，说明连接中断或全量同步卡死 - 注意
master_repl_offset（主节点）和slave_repl_offset（从节点）差值：超过repl-backlog-size（默认1MB）可能触发全量重同步，反复失败就表现为“不参与”
为什么 offset 不动？常见断点位置
复制偏移量停滞，通常卡在三个环节之一：网络连通性、主从身份识别、积压缓冲区可用性。不是所有“连得上”都等于“能复制”。
-
slaveof <master-ip><master-port></master-port></master-ip>手动配置后未生效？检查从节点是否仍处于NOAUTH Authentication required状态——若主节点启用了requirepass，从节点必须配masterauth，否则握手成功但后续命令被拒绝 - 主节点设置了
min-replicas-to-write 2但只有一个从节点在线，此时主节点会拒绝写入，导致master_repl_offset停滞，间接让从节点 offset 无法推进 - 从节点日志出现
Connection refused或read timeout，但cluster nodes显示connected—— 这是集群总线连接正常，但复制专用 TCP 连接失败，需单独查netstat -an | grep :6379（或对应端口）确认 ESTABLISHED 连接是否存在
快速验证复制是否恢复的命令组合
别等客户端报错才行动。用一组原子化命令直接定位复制状态，避免依赖 cluster info 的滞后值。
- 在主节点执行：
redis-cli -h <master> -p <port> role</port></master>→ 应返回master及当前从节点列表和 offset - 在从节点执行：
redis-cli -h <slave> -p <port> role</port></slave>→ 必须返回slave+master_host+master_port+ 实时offset - 对比两者 offset 差值：
echo $(( $(redis-cli -h <master> -p <port> info replication | grep master_repl_offset | cut -d: -f2) - $(redis-cli -h <slave> -p <port> info replication | grep slave_repl_offset | cut -d: -f2) ))</port></slave></port></master>—— 结果持续 > 10000 字节需警惕
修复后仍被客户端忽略？检查客户端 Slot 缓存时效性
即使从节点已恢复复制，Jedis、Lettuce 等客户端可能仍缓存着旧的 CLUSTER NODES 结果，继续把读请求发给已失效的从节点地址，导致“看似恢复实则无效”。
- Jedis：确认是否启用
setRefreshPeriod（单位毫秒），默认 60000（1分钟），太长会导致客户端长期使用过期拓扑 - Lettuce：检查
ClusterClientOptions中topologyRefreshOptions的enableAllAdaptiveRefreshTriggers是否开启，否则不会响应MOVED/ASK自动刷新 - 最直接验证：重启客户端应用进程，或调用其强制刷新 API（如 Jedis 的
refreshCluster()）
真正难处理的，是那些 offset 在缓慢爬升、但始终落后几百 KB 的从节点——它既没彻底断开，又达不到业务可接受延迟，这种“半参与”状态最容易被监控漏掉，也最难判断该切流还是该等。
