容量规划不能脱离业务空谈技术以电商大促交易链路为典型场景。 完整交易核心链路用户登录 → 浏览商品 / 购物车 → 选品、优惠批价、库存校验 → 生成订单 → 支付完成。大促零点的特殊行为大量用户提前加购、领券零点集中触发下单下单环节是流量洪峰核心。电商运营很多策略本质都是削峰把流量打散到大促周期降低瞬间冲击。业务目标到技术峰值的推导路径业务侧给出目标GMV、UV、PV、转化率、客单价。 沿着用户访问路径逐层做漏斗拆解示例大促会场 500 万 UV详情页转化率 60% → 详情页 UV300 万 再向下拆解详情页 QPS、购物车访问、提交订单、创建订单、支付请求逐层衰减得到各个应用的 QPS最终输出下单峰值 QPS、支付峰值 QPS。推导完成后必须和历史大促真实峰值做比对校验修正预估偏差。最终输出的峰值就是系统承诺要支撑的容量指标系统架构、服务器、中间件、数据库都要围绕这个指标做准备。简单概括容量评估不是拍脑袋定机器是业务目标 → 用户漏斗 → 各模块 QPS → 订单 / 支付峰值 → 系统容量指标的完整换算。评估完成之后接下来要做什么原文未写完部分补充拿到各应用的目标 QPS 峰值不等于容量规划结束还要完成三件关键工作区分核心链路与非核心链路交易下单、库存扣减、支付回调属于核心链路必须足额保障容量商品推荐、评价、会员非实时权益等非核心链路可以做降级、限流大促时刻允许牺牲非核心功能保护主交易。预留安全水位不能刚好卡预估峰值业务预估存在乐观偏差会有突发热点商品、外部导流带来额外流量。一般会在计算出的理论峰值之上预留冗余系数例如 1.5‑2 倍安全水位防止流量突刺直接打垮系统。压测验证把纸面指标落地成真实能力通过全链路压测模拟大促流量验证系统在目标峰值下的表现数据库 CPU、缓存命中率、接口 RT、错误率。压测过程中发现瓶颈针对性优化分库分表、缓存热点隔离、异步化、限流熔断。注意压测不能只压单接口必须跑完整交易链路单接口性能好看链路串联后依然会出现瓶颈。预案配套容量够还要有降级止损手段即便容量规划到位依然要准备应急预案关闭非核心接口排队限流保护下单入口优惠计算降级热点商品特殊隔离。容量规划常见误区只看机器数量不从业务漏斗推导 QPS直接拿去年峰值简单乘倍数忽略业务模式变化例如直播带货带来瞬时热点只压单接口忽略链路串联带来的级联问题评估完容量之后不做复盘每次大促重新拍脑袋。两段内容关联思考小团队代码审查 和 容量规划底层思维高度一致代码审查短期迭代速度 VS 长期技术债动态权衡抓高风险不全量铺开容量规划业务预期流量 VS 硬件成本优先保核心链路非核心可降级设置安全水位。都是拒绝极端化抓住风险核心点而不是追求完美全覆盖。