容量规划是提前识别并闭环已知隐患，需拆解用户路径建模流量、分析底层指标定位资源瓶颈、为中间件单独建模、综合计算存储与处理代价，最终通过真实压测验证系统压力边界。
容量规划不是等出问题才去查，而是提前把可能卡住的地方全列出来、挨个验一遍。很多团队直到大促前一周压测崩了，才发现数据库连接池设小了、CDN回源带宽没留余量、甚至时间同步偏差导致分布式锁失效——这些都不是突发故障，全是规划阶段就该识别并闭环的“已知隐患”。
流量模型误判：别把“平均在线”当“峰值压力”
赛事直播、电商大促、抢券活动这类场景，用户行为高度集中。开球前5分钟、零点开抢那一刻，并发请求不是均匀分布，而是秒级冲顶。只按日活×20%估算并发量，大概率低估3~5倍。
- 必须拆解用户路径：进直播间→拉播放地址→建WebSocket→上报心跳→发弹幕→参与竞猜，每一步都是独立接口调用，QPS叠加后远超观看人数
- 实测建议：用真实用户行为轨迹生成压测脚本（如JMeter+录制回放），而非简单并发数递增
- 关键指标要看P999响应延迟和连接建立成功率，不是平均RT
资源瓶颈错位：CPU高≠要加核，内存满≠只加RAM
单看监控图表容易误判。比如Redis节点CPU使用率85%，但实际是AOF重写阻塞主线程；MySQL磁盘IO等待高，根源却是日志刷盘策略没调，而非硬盘太慢。
- 先看iowait、context switch、load average、网络重传率等底层指标，再决定扩什么
- Java服务堆外内存泄漏、Netty连接未释放、glibc线程栈溢出，都可能表现为“CPU高但业务无响应”
- 云上扩容前务必确认实例规格是否支持热升级，否则重启等于停服
依赖链盲区：你扩了应用，没扩ZooKeeper或etcd
微服务架构里，服务发现、配置中心、分布式锁这些基础组件，往往比业务服务更早触达瓶颈。ZooKeeper集群在10万客户端连接下，若未启用观察者节点或会话超时过长，Leader选举频繁就会拖垮整个注册中心。
- 所有中间件都要单独做容量建模：ZK连接数=服务实例数×副本数×客户端重连频次
- etcd的watch事件积压、Consul的健康检查风暴、Nacos的配置变更推送延迟，都得在压测中专项验证
- 建议为配置中心部署独立小集群，与业务流量物理隔离
存储与计算脱节：算对了数据量，没算清处理代价
大数据场景下，1TB原始日志不等于1TB存储需求，也不等于1TB计算资源。压缩率、副本数、索引膨胀、Shuffle数据量、GC开销、序列化反序列化成本，每一层都在吃资源。
- HDFS存储预估公式必须含：原始量 × 增长率n × 副本数 × (1−压缩率) × 索引膨胀系数
- Flink任务内存不能只看heap，off-heap buffer、network buffer、state backend（RocksDB）本地磁盘IO都得单列预算
- 实时作业延迟升高，90%不是CPU不够，而是背压源头没定位到——可能是Kafka分区倾斜，也可能是窗口触发逻辑卡住
真正扛住流量的系统，靠的不是堆机器，而是把每个环节的“最大吞吐”“最小延迟”“最差容错”都写进规划文档，并用真实压测反复证伪。容量规划不是填表格，是给系统画一张带压力边界的数字地图。
