cluster-node-timeout是最关键的起点，它决定节点多久无响应即被标记为pfail，进而影响故障判定与脑裂风险；建议生产环境设为15000ms（内网rtt 2–5ms时），跨机房部署需按rtt≥3倍调整，且必须全节点一致。
cluster-node-timeout 要设得足够小，但不能小于网络 RTT 的 3 倍；否则集群会误判节点失联，频繁触发故障转移。
这不是靠单个参数能解决的问题，而是由 cluster-node-timeout、cluster-require-full-coverage、cluster-quorum、min-replicas-to-write 和 min-replicas-max-lag 这五个参数协同决定的。它们共同约束了“什么情况下允许写”“什么情况下拒绝服务”“多数派如何定义”。
为什么 cluster-node-timeout 是最关键的起点
它决定了节点多久没心跳就被标记为 PFAIL，进而可能升级为 FAIL。设得太大会导致脑裂窗口变长；设得太小（比如低于实际网络抖动周期）会让健康节点被反复踢出，引发不必要的主从切换。
- 生产环境建议值：15000 ms（15 秒），前提是内网 RTT 稳定在 2–5 ms
- 若跨机房部署，RTT 达到 30–50 ms，则
cluster-node-timeout至少设为 150 ms，否则大量PFAIL误报 - 该值必须在所有节点上保持一致，否则 Gossip 协议同步状态时会出现判断偏差
cluster-require-full-coverage 开还是关？取决于你能否容忍部分槽不可用
默认为 yes，意味着只要有一个哈希槽（slot）没有可用节点负责，整个集群就拒绝所有写请求。这看似保守，实则是防止数据写入“黑洞槽”——即某个 slot 的主从全部失联，但客户端仍试图写入。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设为
no可让集群在部分分片不可用时继续服务其余 slot，提升局部可用性 - 但风险是：如果网络分区后，某子集群恰好持有该 slot 的主节点，而原主节点还在另一分区活着，就可能产生写冲突
- 只有当你明确接受“部分数据暂时不可写”，且应用层做了降级或重试兜底，才建议关掉
写安全靠 min-replicas-to-write 和 min-replicas-max-lag 联合控制
这两个参数不是 Redis Cluster 原生支持的，而是从 6.2 开始通过 redis.conf 中的 min-replicas-to-write 和 min-replicas-max-lag 启用的写保护机制（注意：需配合 replica-serve-stale-data no 使用）。
-
min-replicas-to-write 1表示至少要有 1 个在线从节点才允许写 —— 防止主节点孤军奋战 -
min-replicas-max-lag 10表示从节点复制延迟不能超过 10 秒，否则不计入有效副本数 - 二者必须同时满足，否则
WRITE命令返回(error) CLUSTERDOWN The cluster is down - 注意：这个限制只作用于当前主节点，不跨 slot；也不影响
READ请求
cluster-quorum 决定故障转移是否生效，而非“谁来投票”
它定义的是“多少个主节点认可，一次故障转移才算合法”。默认是 quorum = 1，也就是只要一个主节点同意就能升主 —— 这在小型集群（如 3 主）中极危险。
- 正确设置应为：
cluster-quorum≥ceil(N/2)+1，其中 N 是主节点总数（例如 7 主 → quorum 至少为 4） - 它和
cluster-node-timeout共同构成“多数派确认”逻辑：不是看物理连接数，而是看参与 Gossip 投票的主节点数量是否达标 - 若网络分区后，任一子集群拥有的主节点数 cluster-quorum，则无法发起合法故障转移，从而阻断脑裂升主路径
min-replicas-to-write 和 min-replicas-max-lag 的组合效果 —— 它们只在主节点本地生效，不广播、不同步，也不受 Gossip 控制。这意味着你必须手动确保所有主节点配置完全一致，否则某台主节点放行写入，而另一台拒绝，客户端行为就会不一致。
