容量规划是贯穿业务生命周期的闭环工程，需用利特尔法则算并发、按分片与节点双锚点设计es、依量化公式配资源，并通过监控→预测→伸缩→验证自动化闭环落地。

容量规划不是配置清单，也不是一次性的资源申请动作，而是一套贯穿业务生命周期的闭环工程。它既要回答“现在要多少资源”，更要预判“未来什么时候、为什么、需要多少、怎么给”。真正落地有效的容量规划，必须把业务指标、系统行为、硬件边界和运维反馈拧成一股绳。

从QPS到连接数：用排队论算清真实并发需求

高并发不等于高连接数。很多团队盲目放大数据库或缓存连接池，结果引发内核线程争抢、内存暴涨、响应延迟飙升。核心依据是利特尔法则（Little’s Law）：L = QPS × 平均响应时间。例如某服务峰值QPS为8000，SQL平均耗时3ms，则理论活跃连接仅需24个；叠加1.5倍安全冗余，60个连接已足够。再往上加，不是提升性能，而是制造瓶颈。

• 务必使用irate()而非rate()计算瞬时QPS，避免采样周期掩盖毛刺
• 区分主库与从库承载场景：主库按写入+强一致读建模，从库按报表、聚合、异步分析分类估算
• 连接池配置必须与后端服务物理上限对齐——MySQL单机推荐连接数上限 ≈ CPU核数×2 + IOPS并发能力

分片与节点：ES容量的双锚点设计

Elasticsearch的稳定性不取决于堆内存大小，而在于分片规模与节点角色是否收敛。8.3之后，“20分片/GB”已失效，取而代之的是两个硬约束：单节点≤1000分片（非冻结节点），单分片控制在10–50GB之间。低于10GB会导致元数据膨胀、集群状态同步变慢；高于50GB则恢复慢、查询延迟抖动明显。

• 日志类索引建议按天滚动，保留30天即30个索引，每个索引设3主2副本，总分片数可控且可预测
• 节点角色必须显式声明（如node.roles: ["data_hot"]），禁用默认全角色混部，6节点以上集群必须拆分master/data/ingest/coordination角色
• 磁盘水位不能只看总量，要监控各节点差异——某节点达90%会触发只读，整个集群写入中断

资源配比不能拍脑袋：三类典型场景的量化公式

不同中间件对资源敏感维度不同，需按模型推导，而非套用“2核4G”模板：

• RabbitMQ内存 = 并发连接数 × 0.5MB + 队列数 × 单消息均值 × 副本数 × 2
• Redis内存 = key总数 × (key长度 + value长度 + 额外开销) + 集合类结构的指针与哈希表扩容冗余（集合超1万元素建议拆分）
• ES磁盘 = 日原始数据 × 30天 × 1.4（索引膨胀）× 2（1副本）× 1.25（段合并+水位缓冲）

所有公式都要预留20%缓冲空间，并在压测中验证——压测不是测极限，而是找拐点：CPU达70%、GC暂停超200ms、P99延迟翻倍的位置，就是真实容量天花板。

闭环不止于规划：监控→预测→伸缩→验证的自动化链路

静态容量规划正在被淘汰。生产级容量体系必须形成“压测得基线 → 监控采特征 → AI多模型预测（Prophet+LSTM融合） → KEDA/HPA/Karpenter动态调度 → 新资源上线后自动回归验证”的闭环。例如电商大促前7天，系统基于历史流量模式与实时促销曝光量，提前3小时预测出订单服务需扩容至120实例，并在流量抵达前完成Pod就绪与连接池热加载。

• 预测模型必须引入业务因子：节假日、营销活动、外部事件（如热搜、舆情）需作为特征输入
• 弹性策略要带熔断开关——当新扩容节点连续3分钟健康检查失败，自动回滚并告警
• 每次扩缩容后，自动触发轻量级链路压测（如1%流量），验证SLA是否达标