容量规划的经典死法是两种：一种按平均流量规划，牛市一来系统被冲垮；一种按历史峰值翻十倍买设备，预算被砍然后照旧被冲垮。这篇讲一个可操作的容量评估方法：流量怎么估、系统怎么测、水位线怎么定。
容量的单位先定义清楚
交易系统的容量不是"支持多少用户"，是三件要分开测的事：
- 委托峰值 TPS：峰值不在盘中均匀出现，集中在三个瞬间——9:25 集合竞价末段、9:30 连续竞价开市一秒、14:57 深市收盘集合竞价。评估对象是这三个尖峰能不能接住；
- 并发会话数：长连接持有的内存和调度成本，券商营业部批量开盘后连接洪峰是典型场景；
- 回报吞吐：委托、撤单、成交、废单回报的总和。T 型行情日（单边暴涨暴跌）回报洪峰是委托峰值的 1.5~2 倍——一笔大单可能拆出多笔成交，撤单潮另算。
只报"委托 TPS"一个数的容量评估，等于没评估。
峰值怎么估：基准 × 场景系数
估算公式很朴素：
$$ \text{峰值 TPS} \approx \frac{\text{日委托笔数} \times k_{\text{集中度}}}{300}, \qquad k_{\text{集中度}} \approx 25\%\sim35\% $$
集中度系数指前 5 分钟占全天委托量的比例，从自家历史数据实测——不同券商客群结构差异大，别抄别人的。日委托笔数按场景给系数：
- 基准：近一年普通交易日峰值；
- 节假日后首日：×1.3~1.5（假期蓄积的委托开盘集中释放）；
- 重大政策刺激行情（降印花税级别）：×3~5；
- 参照系：2015 年 4~5 月全行业峰值约为 2014 年均值的 8 倍。
最后这条是全行业的心理阴影：容量规划必须按"翻几倍"想，不能按"涨百分之几十"想。行情是非线性的，成交活跃和委托笔数的弹性远超线性外推。
分层测上限：全链取最小值
委托链路每一层有各自的瓶颈资源，逐层压出单项上限：
- 网关：连接数→内存，编解码→CPU；
- 柜台：风控计算→CPU，流水写入→磁盘 IO；
- 撮合：内存操作本身很快，瓶颈在锁竞争——多线程撮合的分片策略决定扩展曲线（《内存撮合 vs 数据库撮合》篇的模型）；
- 数据库：行锁热点，备付金、客户保证金汇总行的串行更新是全局天花板（《热点账户与并行清算》篇同款问题）。
全链容量 = min（各层上限） × 0.6。0.6 是折扣也是水位线，给突发留余量，也给"这台机器今天状态不好"留余量。超过 60% 不是故障，是扩容评审的触发条件。
压测模型：录制回放优于合成脚本
合成流量（脚本生成假报文）的失真之处：真实报文的结构特征是 60% 以上小单、委托价格集中在五档附近、撤单率随行情波动、账户分布有热点。合成脚本把这些分布抹平了，压出来的上限比真实峰值虚高。
工程上靠谱的做法是生产流量录制回放：旁路镜像真实报文（网关做镜像转发，不影响主链路），清洗敏感字段，压测环境按可调速率回放。报文的账户分布、价格分布、大小单比例全保留，播放速率拉到历史峰值的 2 倍，看系统在"超过预估峰值一倍"的世界里能撑多久。数据基础设施和《行情回放系统》是同一套思路，一套投资两处收益。
先行指标：Little's Law 与水位线
排队论里 Little's Law 给了一个极有用的关系：
$$ L = \lambda W $$
在途委托数 $L$ 等于委托到达率 $\lambda$ 乘以委托在系统内的平均时延 $W$。容量见底之前，时延 $W$ 会先抬头——CPU 还有富余的时候，排队已经开始变长。所以在途委托数是容量最灵敏的先行指标，比 CPU、IO 都早。监控上把它和 CPU（60%）、磁盘 IO（70%）、内部队列长度（固定阈值）并排放，任一超线进扩容评审。
水位线的另一半是扩容动作的常备化：备机加入集群的操作提前写成手册并演练过，资源采购流程提前走完。超线才开始走采购的系统，水位线等于白画。
容量规划做到位的标志，是牛市来的时候值班群没人说话。所有指标平稳、所有告警安静，就是这套方法论最好的成绩单。