Redis如何处理集群网络分区_理解少数派网络孤岛由于无法获得选票而停止写入的保护机制

张开发
• 2026/4/18 0:58:35 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

Redis如何处理集群网络分区_理解少数派网络孤岛由于无法获得选票而停止写入的保护机制
Redis Cluster少数派分区自动拒绝写入是因默认启用cluster-require-full-coverage yes要求节点必须属于多数派且槽位全覆盖才允许写入否则返回CLUSTERDOWN错误。少数派分区为什么自动拒绝写入Redis Cluster 默认会在网络分区后让节点数不足多数派N/2 1的分区停止写入——这不是 bug而是通过 cluster-require-full-coverage 配置触发的保护机制。它的核心逻辑是**只有能确认自己属于多数派、且集群槽位覆盖完整时才允许写入**。否则返回 CLUSTERDOWN 错误。比如 6 节点集群3 主 3 从多数派是 4 节点若分区成 33则两边都达不到 4全部拒绝写入若配置为 cluster-require-full-coverage no少数派节点可能继续接受写入但会立刻埋下脑裂隐患该行为不依赖哨兵是 Cluster 内置的 Gossip 共识判断结果由每个节点本地决策cluster-require-full-coverage 的真实影响场景这个配置看似只是“是否检查槽覆盖”实际决定了分区后系统是「保一致性」还是「保可用性」。它不是开关式功能而是一道写入闸门设为 yes默认任意节点发现集群有槽处于 FAIL 状态如原主失联且无从可升所有写请求立即失败客户端收到 (error) CLUSTERDOWN Hash slot not served设为 no节点即使知道部分槽不可用仍尝试服务自己负责的槽但若该槽的主节点在少数派中且没有从节点可接管写入数据将无法被复制恢复后大概率丢失注意它不影响读请求只限制写也不影响故障转移本身只约束写入许可为什么少数派节点“没票”就不能自己升主因为 Redis Cluster 的故障转移不是单点决策而是基于多数派共识的类 Raft 投票过程。一个节点能否晋升为主节点取决于它能否从**至少 N/2 1 个主节点**那里拿到投票响应——这要求它必须能与足够多的其他主节点通信。 Fotor AI Image Generator Fotor 平台的 AI 图片生成器

更多文章