min-slaves-to-write 和 min-slaves-max-lag 通过写前健康检查堵住数据丢失漏洞：仅当至少N个从节点在线且复制延迟≤M秒时才允许写入，否则拒绝命令，将风险前置暴露；二者必须成对配置且协同生效，单独设置无效。
为什么 min-slaves-to-write 和 min-slaves-max-lag 能堵住数据丢失漏洞
Redis 默认异步复制，写命令发给主节点后立刻返回 OK，但此时数据可能还没传到任何一个从节点。一旦主节点宕机、哨兵切换，这部分“已确认但未同步”的数据就彻底消失。这两个配置强制主节点在写入前做一次“复制健康检查”：只有满足“至少 N 个从节点在线 + 最大复制延迟 ≤ M 秒”，才允许写入。否则直接拒绝客户端请求，把风险暴露在写入阶段，而不是藏在故障后。
min-slaves-to-write 和 min-slaves-max-lag 怎么配才不翻车
常见错误是只设 min-slaves-to-write 1 却忽略 min-slaves-max-lag，结果从节点网络抖动时延迟飙升到 60 秒，主节点还在照常写入，照样丢数据。正确做法必须成对使用：
-
min-slaves-to-write 1表示至少要有 1 个从节点处于“可接收复制数据”状态（不是仅连接上，而是能正常 ACK） -
min-slaves-max-lag 10表示该从节点最近一次成功同步的延迟不能超过 10 秒（单位：秒，由repl-backlog-ttl和心跳共同影响） - 两个条件同时不满足时，主节点会返回
MASTERDOWN Link with MASTER is broken或直接拒绝写命令（取决于 Redis 版本），而不是静默接受 - 注意：这个机制只对写命令生效（
SET、XADD等），对GET、DEL等读/删操作无影响
RStream 场景下特别要盯住 AOF + appendfsync always
Redisson 的 RStream 消息本质是写入 Redis Stream 结构，而 Stream 是内存+磁盘双依赖的数据类型。如果只靠主从复制，消息在主节点内存里还没刷盘就宕机，连持久化文件都没生成，哨兵切完新主，旧数据就永远没了。所以必须叠加 AOF 保障：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 开启
appendonly yes，且必须用appendfsync always—— 每条写命令都 fsync 到磁盘，牺牲一点吞吐换强一致性 - 禁用
appendfsync everysec或no，它们在宕机时可能丢失最后 1 秒或全部未刷盘命令 - 验证方式：手动 kill -9 主进程后重启，检查
redis-cli --raw XLEN mystream是否与宕机前一致
脑裂场景下，这两个参数才是真正的“保命开关”
网络分区导致主节点被孤立但仍在运行，客户端继续往它写数据，而哨兵已把某个从节点提为新主——这就是脑裂。此时旧主恢复后降级为从，会清空自身数据并全量同步新主，造成“写进去的数据被主动删除”。min-slaves-to-write 和 min-slaves-max-lag 在这种情况下会立即起效：
- 旧主发现所有从节点失联或延迟超限，自动拒绝后续所有写请求
- 客户端收到错误（如
READONLY You can't write against a read only replica或自定义错误），业务层可触发告警或降级逻辑 - 实际损失被硬性限制在参数设定的时间窗口内（比如 10 秒），而不是任由旧主积累几万条无法回收的消息
真正容易被忽略的是：这个保护只在主节点配置生效，从节点无需配；而且一旦写被拒，必须由业务代码捕获并处理，Redis 不会自动重试或转发到新主。
