min-replicas-to-write和min-replicas-max-lag必须配对启用才能防脑裂，前者限制最小健康从节点数，后者限制最大复制延迟，任一参数单独配置均无效；二者共同作用使旧主在分区时主动拒写，避免数据被覆盖。
Redis 7.0 集群脑裂不是“能不能避免”的问题，而是“写入是否被及时阻断”的问题。默认配置下，脑裂必然发生——只要网络分区存在，且原主节点仍能接收客户端请求，双主就成立。关键在于：让旧主主动拒绝写入，而不是等它恢复后被强制覆盖。
为什么 min-replicas-to-write 和 min-replicas-max-lag 必须配对启用
这两个参数是 Redis 7.0 中防脑裂最直接有效的机制，但单独启用任一参数都无效：
-
min-replicas-to-write控制从库连接数下限（例如设为2），但不关心延迟；若从库连得上却复制严重滞后，仍会放行写入 -
min-replicas-max-lag控制复制延迟上限（例如设为5），但不检查从库数量；若只剩 1 个从库且延迟达标，也满足条件 - 必须同时满足：连接数 ≥ 阈值 且 所有在线从库的
master_repl_offset与主库差值 ≤min-replicas-max-lag秒内产生的增量 - 一旦任一条件不满足，主节点立即返回
READONLY错误，客户端写请求失败 —— 这是数据不被丢弃的前提
cluster-node-timeout 设太小反而加剧脑裂风险
该参数决定节点间心跳超时判定时间，默认 15000（15 秒）。在 Redis 7.0 中调低它并不等于“更快发现故障”，而可能引发误判：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设为
3000（3 秒）：轻微网络抖动（如 GC STW、网卡队列溢出）就触发PFAIL，增加无谓投票和切换频率 - 设为
5000（5 秒）是较稳妥的平衡点：覆盖常见瞬时抖动，又比默认值更早启动仲裁 - 注意：
cluster-node-timeout影响的是 Gossip 层的故障感知，不直接影响写安全；它和min-replicas-*是两套独立机制，不能互相替代
客户端收到 READONLY 后该怎么做？
这不是错误，而是集群在保护你。很多团队把 READONLY 当异常重试，结果放大雪崩：
- 不要盲目重试写请求 —— 延迟写入只会让数据更晚落地，且可能落到已失效的主节点
- 应记录日志并触发告警（如 Prometheus 报
redis_master_write_rejected_total指标突增） - 业务层需支持降级：比如缓存写失败时转存本地队列 + 异步补偿，或切到只读兜底逻辑
- 验证连接的节点是否真为主节点：执行
INFO REPLICATION查role:master和connected_slaves，避免因客户端缓存了过期MOVED路由导致误连
仲裁节点和 Redlock 不解决集群脑裂
这是常见误解。Redlock 是分布式锁算法，仲裁节点常用于 Sentinel 架构，而 Redis 7.0 Cluster 自带去中心化选举机制：
- Cluster 模式下没有“仲裁节点”概念；故障转移由剩余主节点投票完成，依赖
Config Epoch和多数派原则 - Redlock 无法阻止双主写入 —— 它只保证“同一把锁不会被两个客户端同时持有”，但脑裂时两个主节点各自发号施令，锁服务本身也可能分裂
- 真正起作用的是写入拦截（
min-replicas-*）+ 合理超时（cluster-node-timeout）+ 客户端配合（不重试READONLY）
READONLY；客户端是否真能识别并处理该响应；监控是否能捕获写拒绝率突增。没走完这三步，配置只是纸面安全。 
