高可用集群容量不足是多维度渐进式承压所致，需沿数据流路径逐层排查：网络带宽（gossip/raft/同步流量）、存储i/o（%util＞85%、await超阈值）、分片不均（redis槽位或nacos注册倾斜）、故障转移过载（迁移/选举期间资源争抢）及客户端误用（单点连接、大响应体）。
高可用集群容量不足，往往不是“突然爆满”，而是多个维度渐进式承压，最终在某个临界点集中暴露。排查时不能只盯着CPU或内存利用率，得从数据流路径出发，一层层验证资源是否真正被有效利用、是否存在隐性瓶颈。
看带宽和网络连接是否成了隐形墙
Redis、Nacos、etcd等高可用组件对网络极其敏感。千兆网卡打到90%以上，就可能引发请求堆积、超时、重试风暴——尤其是Redis Cluster的Gossip心跳、etcd的RAFT日志同步、Nacos节点间服务同步，全靠持续稳定的内网带宽支撑。
- 用ss -s或iftop -P tcp观察单节点出口流量峰值，重点关注ESTABLISHED连接数与吞吐比值
- 检查客户端是否滥用Pipeline或MGET拉取超大响应体（比如一次返回几MB），这类操作会吃光带宽却不占CPU
- Nacos集群若走内嵌Derby，节点间频繁同步配置快照也会挤占带宽；生产环境务必切到MySQL+主从，把IO压力从内网转移到数据库层
查存储层I/O是否拖垮整个控制平面
etcd、NameNode的QJM、Nacos的MySQL后端，本质都是“元数据+日志”的强一致性系统。它们不拼吞吐量，拼的是低延迟随机写和稳定fsync能力。一块慢盘，就能让整个集群响应飘忽不定。
- 执行iostat -x 1，重点看%util是否持续＞85%，await是否超过20ms（SSD）或50ms（HDD）
- etcd节点上运行etcdctl check perf，它会真实模拟写负载并报告延迟拐点
- NameNode QJM场景下，检查JournalNode磁盘是否混用日志盘和系统盘；多个JournalNode不应部署在同一物理磁盘阵列上
验分片与负载是否真的均匀
集群≠自动均衡。Redis Cluster的16384个槽位如果分配不均，或PHP客户端没正确解析MOVED重定向，会导致某几个节点CPU飙升而其他节点空闲；Nacos集群里，服务注册倾斜也会让Leader节点写压力远超Follower。
- Redis：用redis-cli --cluster check
: 确认槽位分布，再用redis-cli --cluster info核对各节点key数量是否相差超3倍 - Nacos：调用/nacos/v1/ns/operator/metrics接口，对比各节点lookupCount（查询量）和registerCount（注册量）差异
- 检查客户端是否硬编码连接单一节点（如PHP用connect而非pconnect+集群感知库），导致所有请求打到同一入口
盯住故障转移过程中的临时性过载
主从切换、脑裂恢复、slot迁移这些“自愈动作”本身就会制造新压力。比如Redis Cluster迁移期间，源节点要同时处理客户端请求+RDB生成+增量AOF同步；etcd Leader选举时，所有节点会密集广播投票请求。
- 翻看最近72小时的cluster.log或etcd.log，搜索failover、migrating、leader change等关键词，确认是否高频触发
- 检查cluster-node-timeout（Redis）或election-timeout（etcd）是否设得太小，导致网络抖动就被误判为故障
- Redis中启用min-replicas-to-write 1和min-replicas-max-lag 10，可避免从节点掉队时主节点仍强行写入，加剧不一致风险
