min-replicas-to-write和min-replicas-max-lag必须同时配置才有效，因哨兵只判定主节点下线、不校验数据一致性，网络分区时易致双主；二者作用于主节点，要求至少1个从库在线且复制延迟≤10秒才允许写入，缺一不可。
必须配 min-replicas-to-write 和 min-replicas-max-lag，否则脑裂不是“会不会发生”，而是“什么时候发生”。
为什么哨兵自己无法防止脑裂
哨兵只管“谁该当主”，不管“数据是否一致”。它基于主观下线（SDOWN）和客观下线（ODOWN）做判断，但网络分区时，旧主可能还在收写请求，而哨兵已把它标记为下线、选了新主——双主并存就此形成。等网络恢复，旧主被降级为从库，执行全量同步（SYNC 或 PSYNC），分区期间写入的数据就永久丢失。
这不是哨兵的 bug，是它设计边界决定的：它不参与复制过程，也不校验从库数据新鲜度。
所以防脑裂的关键不在哨兵配置本身，而在主节点的写入约束上。
min-replicas-to-write 和 min-replicas-max-lag 怎么配才有效
这两个参数必须同时启用，且作用于主节点（不是哨兵进程），通过 redis.conf 配置：
-
min-replicas-to-write 1：至少有 1 个从库在线且满足延迟要求，才允许主节点接受写请求 -
min-replicas-max-lag 10：该从库的复制偏移量落后主库不得超过 10 秒（单位：秒）
注意：min-replicas-to-write 设为 0 等同于禁用；设为 1 是最小安全值，设更高（如 2）会进一步降低脑裂概率，但增加写失败率。
这两个参数在 Redis 6.0 中默认关闭，必须显式开启。它们只影响主节点的写命令（SET、INCR 等），不影响读或管理命令。
配套必须做的三件事
光配参数还不够，以下三点漏掉任意一个，脑裂防护就形同虚设：
- 所有从节点必须开启
replica-serve-stale-data yes（默认值），否则主节点拒绝写入时，从节点会直接返回错误，客户端逻辑容易崩 - 哨兵的
down-after-milliseconds值不能远小于min-replicas-max-lag，否则哨兵还没判定主节点下线，主节点已因从库延迟超限而拒绝写入，业务误报“写失败” - 客户端必须能处理
READONLY错误——当主节点因上述参数拒绝写入时，Redis 返回该错误码，而不是静默失败；你的代码得重试或降级
最容易被忽略的验证点
很多人配完就以为万事大吉，但没验证过真实效果。最简单的验证方式是手动制造网络分区：
在主节点所在机器上临时屏蔽到某从节点的流量：iptables -A OUTPUT -d <从节点IP> -j DROP，然后观察主节点 INFO replication 输出中的 connected_slaves 和 slave0:lag= 值。再发几个 SET，看是否返回 READONLY。别只信日志，要亲手测。
另外，min-replicas-to-write 不会自动持久化到 RDB/AOF，每次 Redis 重启后需确保配置文件里仍存在——这点在容器化部署中特别容易丢。
