行情系统的容量问题有一个残酷特性：需求不是平稳增长的，是脉冲式的。平时的均值流量和极端行情（开盘集合竞价结束瞬间、千股涨停那天）的峰值差一个数量级以上，而峰值出现的时间不可预测。这篇讲容量怎么估、过载时砍什么、砍的顺序为什么是那个顺序。
容量估算：按洪峰买，承认闲置
带宽和硬件的采购模型只有一种诚实的算法：历史峰值 × 安全系数。全市场洪峰带宽：
$$ B_{\text{peak}} = \sum_{i} r_i \times s \times \text{peak\_factor} $$
$r_i$ 是证券 $i$ 的峰值消息速率，$s$ 是平均消息大小，$\text{peak\_factor}$ 是行情活跃度的峰值放大系数（平时和极端日的比值，经验上 5~10 倍）。注意 $r_i$ 不能取平均值——分布极度不均，1% 的活跃证券贡献 50% 以上的消息量，估算要按分位数或头部证券单独建模。
按峰值买意味着常态下 80% 的容量闲置，这是行情系统的固定成本，没有优化空间。想压缩这块成本的冲动经常出现（"按均值扩容，峰值靠降级"），算账时要记得：降级的触发阈值一旦设错，代价是全体客户同时看到卡死或断流的行情——舆情和监管双杀，比闲置带宽贵得多。
过载保护的第一原则：丢增量，不丢快照
行情数据有个宝贵的性质：增量可丢，快照不可丢。增量丢几条，下一张快照（或重传的增量）会覆盖恢复，下游最终状态正确；快照丢了，新旧状态接不上，客户端的盘口就是错的，而且错得无声无息。
所以过载时的第一刀永远是砍增量频率——行情服务器对同一证券的增量做合并（比如 100ms 窗口内只发最新一次状态变化），带宽立降，下游延迟增加 100ms，无伤大雅。这在代理层做（公网客户端对延迟更不敏感）比在接收层做好，离数据源越近砍得越要谨慎。
降级阶梯
过载继续升级，按"伤害用户感知从小到大"的顺序砍：
第一级：合并刷新。增量合并窗口拉长（50ms → 200ms → 1s）。几乎无感知，带宽收益立竿见影。
第二级：降维度。砍逐笔数据只留快照（对只看盘口的用户无影响，做订单流的用户受损）、砍 L2 只发 L1（十档变五档）。维度砍了，信息就真的没了，所以对订单流类数据服务要单独承诺 SLA——付费客户的逐笔流不能和非付费的盘口共用降级开关。
第三级：降订阅。非活跃证券（很久没成交、没人看的票）停止推送增量，客户端显示延迟标识；自选股覆盖的证券永远豁免（用户主动表达的意图优先级最高）。这一步对散户感知接近零——没人看的票本来也没人看——收益却可观，因为长尾证券在洪峰时同样消耗分发资源。
第四级：丢代理连接。行情代理对慢客户端（写缓冲积压）主动断连，逼迫客户端重连走快照同步。客户端体验是"闪断一下"，比代理被拖垮全员卡死好。
砍的顺序为什么是这样：越靠前的级别，砍的是"重复信息"（增量本质是冗余传输），越靠后砍的是"独占信息"。从信息论角度看，这就是按"单位带宽损失的信息量"从低到高排序。
与交易系统的隔离是硬约束
前面《行情分发》提过行情专网，这里再强调一次它的过载意义：行情洪峰绝不能把交易流量挤死。行情系统过载时丢包是"数据晚一点到"，交易系统被挤是"委托撤不了"——监管事故。物理隔离（独立网卡、独立交换机队列）比任何 QoS 软件策略都可靠，QoS 标记在队列打满时照样失效。
压测验证：回放是唯一可信的手段
容量规划的数字再漂亮，没压过就是猜。行情压测的可行手段就是《行情回放系统》的加速回放：把历史洪峰日的原始流 5 倍速、10 倍速放给被测链路，观察丢包率、处理延迟、降级开关是否按预期触发。造合成流量（写个程序狂发 UDP）测不出真实模式——真实洪峰的消息大小分布、证券集中度、频道分布都有规律，合成流量要么太温柔要么把系统打死，给不出"降级在第几级生效"这种关键结论。
生产侧的监控指标前面几篇都提过：丢包率、空洞频率、代理延迟分位数、各级降级开关的触发次数。把这些指标接到告警上，让系统在"快要不行"而不是"已经不行"的时候告诉你。