必须同时配置min-slaves-to-write和min-slaves-max-lag，缺一不可；二者构成联动开关，仅当存活从节点数≥前者且至少一个从节点延迟≤后者时主节点才允许写入，单独配置任一参数均无法防止脑裂。
必须在主节点上启用 min-slaves-to-write 和 min-slaves-max-lag 双参数，缺一不可；否则故障转移过程中旧主仍可写入，恢复后数据被覆盖。
为什么只配一个参数没用
这两个参数是联动开关：只有当同时满足「存活从节点数 ≥ min-slaves-to-write」且「至少一个从节点 lag ≤ min-slaves-max-lag」时，主节点才允许写入。单独开 min-slaves-to-write 1 但 lag 拉到 60 秒，主节点照常收写请求；单独设 min-slaves-max-lag 5 但只剩 0 个从节点在线，它也无从校验——结果都是脑裂高发。
常见错误配置：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
min-slaves-to-write 1+min-slaves-max-lag 0：lag=0 几乎不可能达成，等于永远拒绝写入 -
min-slaves-to-write 2但集群实际只有 1 个从节点：启动即拒绝所有写，服务直接不可用 - 值设得过大（如
min-slaves-max-lag 60）：失去限流意义，和不配没区别
参数怎么设才合理
不能拍脑袋定数字，要基于实测复制延迟和拓扑容错能力：
-
min-slaves-to-write应 ≥ 当前部署中「跨机房/跨可用区存活的从节点最小数量」。例如 3 个从节点分在 A/B/C 三个机房，单机房故障后最多剩 2 个，那就设为 2 -
min-slaves-max-lag必须 ≤ 实测 P99 复制延迟的 2–3 倍。用redis-cli -h 主IP info replication查slaveX.repl_ack_log字段，连续观察 1 小时取 P99 值 - 生产建议起始值：
min-slaves-to-write 2、min-slaves-max-lag 8000（8 秒），再根据监控调优
客户端不配合，配置就白搭
即使主节点按规则拒绝写入，客户端若无视 BUSYLOAD 或 READONLY 错误继续重试，或缓存旧 master 地址不刷新，照样导致“看起来丢数据”：
- Java 客户端（Lettuce）必须启用
sentinelRefresh并设refreshPeriod=2000，不能依赖默认 60 秒 - Python 客户端（redis-py）调用
Sentinel.discover_master("mymaster")前，先检查连接是否返回ROLE为["master"]，不是就丢弃重连 - 禁止在业务层捕获
BUSYLOAD后降级写本地磁盘——这会掩盖真实脑裂，且无法保证最终一致
真正容易被忽略的是：配置生效后必须验证主节点是否真能触发拒绝。用 tc 在从节点机器上模拟丢包，观察 INFO stats 中 rejected_connections 是否上涨，而不是只看哨兵日志有没有切主。
