Redis Cluster少数派分区自动拒绝写入是因默认启用cluster-require-full-coverage yes，要求节点必须属于多数派且槽位全覆盖才允许写入，否则返回CLUSTERDOWN错误。
少数派分区为什么自动拒绝写入
Redis Cluster 默认会在网络分区后，让节点数不足多数派（N/2 + 1）的分区停止写入——这不是 bug，而是通过 cluster-require-full-coverage 配置触发的保护机制。它的核心逻辑是：**只有能确认自己属于多数派、且集群槽位覆盖完整时，才允许写入**。否则返回 CLUSTERDOWN 错误。
- 比如 6 节点集群（3 主 3 从），多数派是 4 节点；若分区成 3+3，则两边都达不到 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 个主节点**那里拿到投票响应——这要求它必须能与足够多的其他主节点通信。
- 分区后，A、B 两个主节点彼此可达，但和 C、D、E 失联 → 它们最多只能互相投票，凑不够 3 票（5 主集群需 3 票）
- 它们发出去的
FAILOVER_AUTH_REQUEST消息石沉大海，超时后放弃选举 - 此时 A、B 仍运行着，但状态卡在
PFAIL，不会主动降级，也不会升级；客户端连过去，发现槽位没主，就报错 - 关键点：不是它们“不想升”，而是协议根本不允许它们在未获法定票数时变更角色
容易被忽略的配置组合陷阱
单独调 cluster-require-full-coverage 不够，真正决定少数派行为的是它和 cluster-node-timeout、min-replicas-to-write 的配合效果：
-
cluster-node-timeout 15000（默认）太短 → 瞬时抖动就触发 PFAIL，增加误判；建议生产环境调至30000或更高 -
min-replicas-to-write 1+min-replicas-max-lag 10可让主节点在从节点延迟过大或断连时主动拒写，与集群层面的多数派保护形成双保险 - 但若同时开启
cluster-allow-writes-on-stable-cluster yes（非默认），会绕过多数派检查——这个隐藏配置极少文档提及，却可能让少数派“偷偷写入”，务必禁用
最危险的情况不是节点宕机，而是网络分区后你没意识到某些节点已变成“静默写入孤岛”——它们不报错、不告警，只安静地积累不一致数据，等恢复时才爆发。
