min-slaves-to-write 是防脑裂的第一道闸门，因其在主节点本地实时拦截写入：当在线且延迟达标的从节点数不足时立即返回 MASTERDOWN 错误，不依赖哨兵投票或故障转移完成，从而在脑裂发生初期就阻断旧主继续写入孤立数据。
必须配 min-slaves-to-write，否则主库网络分区后仍可写入，脑裂风险极高。
为什么 min-slaves-to-write 是防脑裂的第一道闸门
脑裂（split-brain）不是哨兵没选好主的问题，而是主节点在「被判定为客观下线前」仍能接受写请求——比如主库所在机器网络断连但进程未死，哨兵还没达成 ODOWN 共识，此时客户端还在往旧主写数据，而新主已在另一边开始服务，两边数据就此分叉。
min-slaves-to-write 的作用就是：当主库发现在线从库数量 低于设定值 时，直接拒绝写命令（返回 MASTERDOWN 错误），强制业务感知异常，而不是继续写入孤立数据。
它不依赖哨兵投票，也不等故障转移完成，是主库自身最及时、最底层的自我保护机制。
min-slaves-to-write 和 min-slaves-max-lag 怎么配才有效
这两个参数必须成对使用，单独设 min-slaves-to-write 效果有限。真实场景中，从库“在线”不等于“数据新鲜”，网络延迟或复制积压都可能导致数据滞后。
-
min-slaves-to-write 1：至少要有 1 个从库连接着（但可能 lag 5 秒） -
min-slaves-max-lag 10：该从库的复制偏移量落后主库不能超过 10 秒
只有同时满足两个条件，主库才允许写。生产建议值：
- 三节点集群（一主两从）：设
min-slaves-to-write 1+min-slaves-max-lag 5 - 五节点集群（一主四从）：可设
min-slaves-to-write 2+min-slaves-max-lag 3，提升一致性水位
注意：min-slaves-max-lag 单位是秒，但实际判断依据是复制偏移量（offset）差值，Redis 内部每秒采样一次 lag，所以设 3 秒 ≈ offset 差 ≤ 3000 条命令（取决于写入频率）。
配置生效后，客户端会遇到什么错误
一旦触发限制，所有写命令（SET、INCR、HSET 等）都会立即失败，返回：
MASTERDOWN Link with MASTER is broken
这不是连接错误，而是主库主动拒绝写入。客户端必须处理这个错误：
- 不能静默忽略或重试（重试仍打到同一主库，无效）
- 应降级为只读、缓存失效、或触发告警人工介入
- Spring Data Redis 默认会抛
RedisSystemException，需捕获MASTERDOWN字符串做分支处理
切记：这不是故障转移过程中的临时状态，而是主库仍在运行但已自我隔离——此时哨兵可能还在协商 ODOWN，你看到的“主库还活着”，恰恰是最危险的时候。
容易被忽略的三个实操细节
很多人配了参数却没生效，问题常出在这几个地方：
- 主节点配置文件里没加
requirepass（如果有密码），而从节点用masterauth连接，会导致从库虽然连上，但复制握手失败，INFO replication显示slave0:ip=... state=offline，实际从库数为 0 ——min-slaves-to-write自然不满足 - 哨兵配置里没同步设置
sentinel auth-pass <master-name> <password>，导致哨兵无法向主库发送CONFIG SET动态修改参数，重启主库才能生效 - 用
redis-cli --raw CONFIG GET min-slaves-to-write检查时，返回空值 ≠ 未配置，可能是主库启动时未加载该配置项（老版本 Redis 或配置文件路径不对）
最稳妥的方式：在主节点上执行 CONFIG SET min-slaves-to-write 1 和 CONFIG SET min-slaves-max-lag 5，再用 CONFIG REWRITE 持久化，最后确认 INFO replication 中 connected_slaves 和 slave0:lag 值符合预期。
