核心是min-slaves-to-write和min-slaves-max-lag必须同时生效，前者限定合格从节点数量，后者定义复制延迟阈值（单位秒），仅当在线且lag≤阈值的从节点数达标时主节点才允许写入，否则返回masterdown拒绝写请求。
主从切换期间丢数据，不是靠加 retry 或换客户端能解决的，核心是让旧主在风险升高时主动拒写——关键配置只有 min-slaves-to-write 和 min-slaves-max-lag 两个参数必须同时生效。
为什么配了 min-slaves-to-write 还拦不住写入
这个参数单独设了没用，它只看“合格从节点数”，而合格与否由 min-slaves-max-lag 和真实复制状态共同决定：
-
min-slaves-to-write 2表示至少要有 2 个从节点在线且 lag ≤ 阈值，才允许写；只要有一个从节点state=online但lag=15（而你设了min-slaves-max-lag 10），它就不算数 - 执行
redis-cli INFO replication，重点检查每行slaveX的state=online和lag值，connected_slaves数字只是连接数，不是可用数 - 从节点重启后处于
state=sync阶段时不参与计数，这段时间主节点可能已开始拒写
min-slaves-max-lag 的单位和测量逻辑容易被误解
这个值不是网络 ping 延迟，而是从节点向主节点回传 ACK 的滞后时间（单位秒），反映的是复制积压实际进度：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设为
10意味着：如果所有存活从节点的lag都 >10，主节点立刻返回MASTERDOWN错误，拒绝所有写命令 - 监控时要看
INFO replication中每个slaveX.repl_ack_log字段，而不是依赖redis-cli --latency - 若业务写入峰值高、repl-backlog-size 太小（默认仅 1MB），会导致从节点断连重连时触发全量同步，
lag瞬间飙到几百秒，直接触发拒写
集群模式下别白费劲调 WAIT 命令
WAIT 在 Redis Cluster 中完全无效，它只作用于单主多从拓扑，且确认的只是“收到包”，不是“已执行”或“已持久化”：
-
WAIT 1 5000返回 1，只说明某个从节点 TCP 层回复了 ACK，不代表它已将XPUSH写入内存或 AOF 文件 - 集群客户端自动重定向时，
WAIT对刚切走的 slot 完全不生效；旧主仍在处理哈希槽请求，WAIT根本触达不到新主 - 真正起效的是让主节点在脑裂苗头出现时就停写——这只能靠
min-slaves-to-write+min-slaves-max-lag组合实现
最容易被忽略的点是：这两个参数必须配合足够大的 repl-backlog-size（比如 50MB）和开启 AOF（appendonly yes + appendfsync everysec）才有实际意义。否则，即使主节点拒写了，旧主恢复后仍会因全量同步清空本地 RStream 数据。
