容量规划在交易系统里有个残酷的特点：系统平时 95% 的时间运行在 5% 的负载上，真正考验它的是一天里那几十秒。9:30 开盘集合竞价撮合瞬间、14:57 深市收盘竞价、突发行情时的委托洪峰——容量不是按"平时够不够"算的，是按"那几十秒扛不扛得住"算的。这篇讲峰值怎么估、瓶颈在哪、以及为什么平均值思维在这个领域必然翻车。
峰值不是平均值的倍数：到达过程的形态
委托到达不是泊松过程。平稳期它近似泊松（间隔服从指数分布），但峰值期的到达是自激发的：行情异动 → 触发大量策略和人工反应 → 更多委托改变盘口 → 又触发更多反应。这种 Hawkes 式的正反馈让到达率在秒级内翻十倍。
所以容量估算的第一步不是预测，是测量：把历史峰值日的委托流按毫秒分桶，得到到达率曲线 $\lambda(t)$ 的经验分布。A 股的经验形态（以深市 2024 年数据量级为例）：9:15~9:25 集合竞价委托以数十万笔/分钟的速率涌入并被缓冲，9:30:00 撮合释放的瞬间产生全天的最高单秒速率，全天约三分之一的委托集中在开盘后的前 30 分钟；14:57 收盘竞价是第二个尖峰。规划目标取"历史最大秒级速率 × 安全系数 2~3"——安全系数不是拍脑袋，是为测量覆盖不到的场景留的：新产品上线（注册制新股首日无涨跌幅）、新策略品种出现（2024 年程序化新规前后）、以及未来三年的业务增长。
平均思维错在哪，排队论一句话说透：M/M/1 队列的平均等待时间
$$ W = \frac{1}{\mu - \lambda} $$
$\lambda$ 逼近 $\mu$ 时 $W$ 发散——不是"变慢一点"，是无界变慢。利用率 50% 时平均排队一拍，80% 时排队四拍，95% 时排队十九拍。延迟的增长是非线性的，容量的余量必须在到达率的不确定性之上留足，"按均值规划 + 峰值时祈祷"不是策略。
瓶颈定位：全链路谁最慢
容量是链路的属性，不是某个模块的。一笔委托的路径：接入网关 → 会话校验 → 事前风控 → 报盘 → 撮合（交易所侧）→ 回报 → 柜台状态更新。每一跳都是一个小排队系统，链路吞吐由最慢一跳决定。
工程上要先做延迟分解：压测时给每一跳打时间戳，算出每跳的 $\mu$。经验上瓶颈几乎总出现在两处：撮合循环（单线程，$\mu$ 有硬上限）和数据库热路径（余额冻结/解冻的并发写）。找到瓶颈之后的扩容手段各不相同：
- 撮合是串行的——不能靠加线程，只能靠每拍更快（内存撮合是这笔账的答案）；
- 风控检查是并行的——不同检查项（资金、持仓、黑名单）之间无依赖，可以并行流水线化，预算总共几百微秒（事前风控篇讲过）；
- 账务写是哈希可分的——按账户分片，不同账户的余额更新并行，热点账户（自营做市账户）单独隔离（热点账户篇的方案）。
容量规划的落地物是一张预算表：峰值秒级到达率 $\lambda_{peak}$，每跳的服务率 $\mu_i$，要求每跳满足 $\mu_i \geq 3\lambda_{peak}$（对应利用率 33%，排队时间可控）。任何一跳不满足就是缺口，缺口要么补硬件要么改架构，没有第三种选择。
三个被低估的容量消耗项
只按委托笔数规划会漏掉三个同样消耗容量的流量源，前文各篇都埋过伏笔，这里收拢：
- 撤单：与委托进同一个 FIFO 队列，量化策略的撤单率普遍在 50% 以上——有效到达率是 $\lambda_{\text{order}} + \lambda_{\text{cancel}}$，不是 $\lambda_{\text{order}}$；
- 回报：一笔部成拆多条回报，热点证券的回报放大系数可以到 3~5，回报处理线程的容量要按委托峰值 × 放大系数算；
- 集合竞价的缓冲释放：9:30 撮合瞬间，积压的委托不是"到达"，是"已经到达、等待集中处理"——到达率的测量要把 9:15~9:30 的缓冲量算进 9:30:00 的那一秒。
压测也要对这三者建模：用录制的生产流量回放是底线，但回放的是"昨天的峰值"；更狠的做法是构造合成流量，把到达过程做成 Hawkes 自激发形态，专门打"秒级十倍"的场景。2015 年股灾期间多家券商柜台瘫痪，事后复盘的技术结论高度一致：系统是按历史平均的 3 倍设计的，而峰值是平均的 20 倍——测量覆盖不了没见过的东西，这恰恰是压测存在的意义。