cluster info 不能检测网络分区，它仅显示本节点视角的集群状态，分区时仍可能显示 cluster_state:ok；真正可靠的方法是跨至少两个节点执行 cluster nodes 并比对 connected 状态与 fail 标记。
cluster info 命令本身不能直接检测网络分区，它只反映当前节点视角下的集群聚合状态。真实网络分区发生时，cluster info 很可能仍显示 cluster_state:ok，而部分节点已互相失联——这是最危险的误判场景。
为什么 cluster info 会“假装正常”
Redis Cluster 使用 Gossip 协议异步传播节点状态，每个节点只维护自己看到的视图。cluster info 输出的是本节点本地缓存的汇总信息，不触发跨节点一致性校验。当分区发生（如 A/B 区互断，但各自内部连通），A 区节点查 cluster info 看到 3 个节点在线、状态 ok；B 区同理——两边都“自以为正常”。
- 分区中任一子集只要满足多数派（quorum），就能继续接受写入，造成数据分裂
-
cluster_state:ok仅表示“本节点认为槽位分配完整”，不保证所有主节点可达 - 没有自动告警机制：即使
cluster_known_nodes数量变少，只要未低于cluster-node-timeout阈值，状态不会变
真正能暴露分区的操作：对比 cluster nodes 的视角差异
必须从**至少两个不同节点**分别执行 redis-cli -c -h <ip> -p <port> cluster nodes</port></ip>，人工比对输出中各节点的 connected 状态和标记（fail / nofail）是否一致。
- 重点看字段末尾：例如
123...abc 10.0.1.10:6379@16379 master - 0 1744824123000 1 connected 0-5460中的-表示该节点认为目标节点“在线且无故障”；若显示fail，说明本节点已将其标记为下线 - 如果节点 A 认为节点 B 是
fail，但节点 C 认为 B 是-，大概率存在单向延迟或分区边界 - 检查
ping-sent和ping-recv时间戳差值：若某节点的ping-recv长期停滞（比如超过cluster-node-timeout），说明收不到对方心跳
配合 INFO replication 检查主从同步断裂
网络分区常导致主从链路中断，但 cluster info 完全不体现这点。需在疑似从节点上运行 INFO replication，观察关键字段：
-
master_link_status:down—— 直接证明与主节点 TCP 连接已断 -
master_last_io_seconds_ago:120—— 值持续增长，说明复制心跳停止 -
slave_repl_offset停滞不动，且明显小于主节点的master_repl_offset—— 数据已开始落后 - 注意：从节点自身
cluster nodes输出里仍可能显示master节点为-，因为它还能连上其他节点（非其 master），造成假象
自动化检测的关键盲区
任何只依赖单点命令（包括 cluster info 或单次 cluster nodes）的脚本，都无法可靠发现分区。必须做跨节点状态比对，且要覆盖至少三个不同物理位置的节点（避免同机房单点故障干扰判断）。生产环境建议用定时任务采集所有节点的 cluster nodes 输出到中心存储，再用 diff 工具识别不一致行——这才是真正落地的检测方式。手动跑一次 cluster info 看到 ok 就放心，等于在分区发生时主动关闭告警。
