第一章：性能基准与目标设定

做市商系统，说白了就是跟时间赛跑。你想想看，别人报价比你快1微秒，订单就被抢走了。我做了十几年低延迟交易系统，见过太多团队一上来就闷头优化，结果连自己系统到底多快都说不清楚。

这一章，咱们先把地基打牢。没有基准，优化就是瞎忙活。

1.1 核心性能指标：三个维度

做市商系统的性能，我习惯从三个维度去衡量。缺一个都不行。

指标	定义	典型目标（高频做市）
延迟（Latency）	从事件发生到系统响应的总耗时	P50 < 10μs, P99 < 50μs
吞吐量（Throughput）	单位时间内处理的订单/报价数量	> 100万笔/秒
抖动（Jitter）	延迟的波动程度，通常用标准差衡量	P99 - P50 < 20μs

1.2 延迟：到底在测什么？

很多人一上来就测「端到端延迟」，我觉得这太粗糙了。做市商系统的延迟，至少要拆成三段来看：

• 网络延迟：从网卡到内核协议栈，再到用户态。这部分我习惯用DPDK绕过内核，能省下5-10微秒。
• 业务逻辑延迟：定价引擎、风控检查、订单组装。这里最容易出幺蛾子，我遇到过有人用Python写了个正则表达式做风控，一次匹配花了200微秒。
• 交易所延迟：这个我们控制不了，但必须监控。如果交易所突然变慢，你得知道是它的问题，不是你的问题。

1.3 吞吐量：别被峰值骗了

吞吐量这个指标，很多人喜欢报峰值。但做市商系统是持续运行的，峰值没意义。

我建议用 持续吞吐量 和 突发吞吐量 两个指标：

• 持续吞吐量：系统在稳定状态下，每秒能处理的订单数。比如每秒50万笔，持续10分钟不掉速。
• 突发吞吐量：系统在短时间内（比如1秒）能承受的最大压力。比如行情剧烈波动时，每秒涌入200万笔订单，系统不能崩溃。

嗯，这里要注意。很多系统持续吞吐量做得不错，但一遇到突发流量就崩。我见过一个案例，某团队用消息队列做订单处理，平时跑得好好的，结果某天行情异动，队列积压到内存溢出，直接宕机了。

1.4 抖动：最容易被忽视的杀手

抖动这东西，说白了就是延迟的不稳定性。为什么做市商特别怕抖动？

因为交易所的撮合机制。如果你的延迟忽高忽低，你的报价就会忽快忽慢。交易所的算法会认为你「不可靠」，然后降低你的优先级。更惨的是，如果抖动导致报价超时，直接算你违规。

我曾经帮一个客户排查问题，他们的P50延迟只有8微秒，但P99能到200微秒。查了半天，发现是Java的GC在作祟。每次GC触发，系统就卡一下。后来换成C++实现核心路径，抖动直接降到了5微秒以内。

1.5 设定合理的SLA

SLA不是拍脑袋定的。我一般按这个流程来：

1. 先跑一周的基准数据，看看系统真实表现。
2. 分析业务需求。比如做市商要求报价必须在10微秒内返回，那你的SLA就得比这个更严。
3. 留出安全余量。我习惯在目标值上再加30%的余量。比如业务要求10微秒，我定6微秒。为什么？因为系统总有波动，你得给自己留点犯错的空间。

举个例子，一个典型的做市商系统SLA可能是这样：

指标	目标值	告警阈值	熔断阈值
P50延迟	< 8μs	> 12μs	> 20μs
P99延迟	< 30μs	> 50μs	> 100μs
吞吐量	> 80万/秒	< 60万/秒	< 40万/秒
抖动（P99-P50）	< 15μs	> 25μs	> 40μs

1.6 建立性能基准测试流程

基准测试不是跑一次就完事了。我建议把它做成自动化流程，每次代码变更都跑一遍。

具体步骤：

1. 准备测试环境：硬件配置、网络拓扑、软件版本全部固定。我习惯用单独的测试机，避免被其他任务干扰。
2. 编写测试脚本：模拟真实行情和订单流。注意要包含正常流量和突发流量两种场景。
3. 收集数据：用硬件时间戳记录每个阶段的耗时。我推荐用 perf 和 eBPF 做细粒度分析。
4. 生成报告：自动计算P50、P99、P999、吞吐量、抖动等指标。
5. 对比基线：每次测试结果自动跟上次对比，如果延迟恶化超过10%，自动告警。

1.7 知识体系总览

下面这张图，是我对性能基准与目标设定的整体理解。你可以把它当作本章的思维导图：

1.8 小结

这一章我们聊了三个核心指标：延迟、吞吐量、抖动。我个人觉得，抖动是最容易被忽视但最致命的。设定SLA时，记得留余量。基准测试要自动化，每次代码变更都跑一遍。

嗯，内容就这些。下一章我们会深入延迟分析，聊聊怎么用 perf 和 eBPF 找到系统的瓶颈点。

---

公众号:蓝海资料掘金营，微信deep3321