min-replicas-to-write 与 min-replicas-max-lag

两个参数的作用

min-replicas-to-write 和 min-replicas-max-lag 是 Redis 中防止脑裂数据丢失的”黄金组合”。它们共同定义了主节点在什么条件下才能接受写入请求。

参数详解

min-replicas-to-write

min-replicas-to-write 1

含义：主节点在写入数据之前，至少需要有 N 个从节点与其保持连接。如果连接的从节点数量少于这个值，主节点会拒绝写入。

• 默认值：0（关闭，即不检查从节点数量）
• 建议值：1 或 2（取决于副本数量）

min-replicas-max-lag

min-replicas-max-lag 10

含义：从节点的复制延迟（lag）不能超过 N 秒。任何连接的从节点中，如果某个从节点的延迟超过这个值，主节点也会拒绝写入。

• 默认值：10（秒）
• 建议值：取决于业务对数据一致性的要求

两个参数如何配合工作

# 伪代码：主节点写入前的检查逻辑
def can_accept_write():
    connected_replicas = get_connected_replicas()
    lagging_replicas = count_replicas_with_lag_gt(min_replicas_max_lag)
    good_replicas = connected_replicas - lagging_replicas

    if good_replicas < min_replicas_to_write:
        return False  # 拒绝写入，返回错误
    return True

关键点：
1. 只计算”已连接且延迟达标”的从节点
2. 对比配置要求的最小从节点数
3. 如果不满足条件，主节点返回错误信息

实战示例

配置 1：严格保护

min-replicas-to-write 2
min-replicas-max-lag 5

当有 2 个从节点时：
– 需要 2 个从节点都连接且延迟 < 5 秒 才能写入
– 任何从节点断开或延迟过高 → 拒绝写入

配置 2：适度保护

min-replicas-to-write 1
min-replicas-max-lag 10

当有 2 个从节点时：
– 只需要 至少 1 个从节点连接且延迟 < 10 秒 即可写入
– 所有从节点都断开 → 拒绝写入
– 1 个断开但另 1 个正常 → 可以写入

配置 3：关闭保护

min-replicas-to-write 0

不检查从节点状态，只要有网络就可写入。这是默认配置，也是数据安全性最差的配置。

脑裂防护效果对比

权衡：可用性 vs. 一致性

强一致优先（CP）

min-replicas-to-write 2  # 需要所有从节点在线
min-replicas-max-lag 5

• 数据安全性最高
• 但当一个从节点宕机时，整个主节点不可写
• 牺牲了可用性

高可用优先（AP）

min-replicas-to-write 0

• 主节点始终可写
• 但脑裂时数据丢失风险高
• 保证了可用性

折中方案

min-replicas-to-write 1
min-replicas-max-lag 10

• 至少需要 1 个从节点在线
• 主从延迟不超过 10 秒
• 在可用性和数据安全性之间取得平衡

使用注意事项

从节点数量

配置值不能超过实际从节点数量。如果只有 1 个从节点，却设置 min-replicas-to-write 2，那么主节点永远无法写入。

适用于哨兵架构

这两个参数同样适用于主从+哨兵架构，不仅限于 Cluster 模式。在主从复制中配置同样有效。

不是银弹

这两个参数能有效减少脑裂数据丢失，但不能完全消除所有数据丢失风险。例如：

• 主节点与从节点连接正常但已经不再复制数据的情况（某些 bug 场景）
• 同步成功后主节点立刻宕机，从节点尚未保存的情况

面试重点

• min-replicas-to-write：至少 N 个从节点连接
• min-replicas-max-lag：从节点延迟不超过 N 秒
• 两者共同决定主节点是否可写
• 核心作用：脑裂时阻止旧主节点继续写入
• 需要在可用性和一致性之间做权衡
• 默认值 0 意味着不做防护

总结

min-replicas-to-write 和 min-replicas-max-lag 是 Redis 提供的最简单有效的脑裂防护手段。它们的本质是将”主节点写入权限”与”从节点健康状态”绑定，当从节点全部失联时自动切断写入路径，从而在源头上阻止脑裂数据丢失。合理配置这两个参数，可以在不用引入额外复杂机制的情况下显著提升 Redis 集群的数据安全性。