1. 性能调优概述：什么是交易系统性能、为什么需要调优、性能指标、调优的全局观
1.1 交易系统性能到底是什么？
说实话，很多人一听到「性能」两个字，第一反应就是「快」。没错，快很重要。但交易系统的性能，远不止「快」这么简单。
我个人习惯把交易系统性能定义为：系统在单位时间内，稳定、正确地处理交易请求的能力。这里面有三个关键词：稳定、正确、处理能力。缺一不可。
你想想看，一个系统跑得飞快，但每秒钟丢了几笔订单，这叫性能好吗？显然不是。或者系统吞吐量很高，但时不时卡顿一下，导致部分订单延迟了几百毫秒——这在高频交易里，可能就是致命的。
我在项目中遇到过一位客户，他们的系统延迟很低，但抖动特别大。平时延迟只有 10 微秒，可每隔几分钟就会跳到一个毫秒级。结果呢？他们的策略在回测时表现完美，一上线就亏钱。为什么？因为实盘环境下的抖动，把策略的假设全打破了。
核心观点：交易系统性能 = 低延迟 + 高吞吐 + 低抖动 + 高正确性。四者缺一不可。
1.2 为什么需要调优？—— 不调优的代价
你可能觉得，系统能跑就行，何必折腾？嗯，我以前也这么想。直到有一次，我负责的一个期货交易系统，在行情剧烈波动时，订单处理延迟从 50 微秒飙升到了 5 毫秒。结果呢？滑点损失直接让客户亏了六位数。
从那以后，我深刻认识到：性能调优不是锦上添花，而是生存刚需。具体来说，调优的必要性体现在这几个方面：
- 竞争压力：在同等策略下，延迟低 1 毫秒，可能就是盈利与亏损的分界线。我见过太多团队，因为系统慢了几微秒，被对手抢走了流动性。
- 成本控制：性能差的系统，需要更多的硬件资源来支撑同样的业务量。说白了，就是烧钱。调优能让你用更少的机器，扛住更大的流量。
- 风险规避：系统性能瓶颈往往在极端行情下暴露。平时没事，一遇到「黑天鹅」就崩盘。调优是为了让系统在极端情况下也能稳定运行。
- 业务扩展：交易量增长是必然的。如果系统不调优，业务量翻倍时，你可能需要重新架构——那代价就大了。
避坑指南：我曾经见过一个团队，为了追求极致延迟，把所有逻辑都塞进一个线程里。结果呢？一旦某个环节出问题，整个系统都卡死。调优要讲究平衡，不能走极端。
1.3 核心性能指标：延迟、吞吐量、抖动
聊性能调优，绕不开这三个指标。我一个个说。
1.3.1 延迟（Latency）
延迟，说白了就是「从发起到完成，花了多少时间」。在交易系统里，通常指从订单发出到收到确认的时间。
延迟又分几种：
- 网络延迟：数据在网线上跑的时间。光速是极限，但实际受路由、交换机影响。
- 处理延迟：CPU 计算、内存访问、磁盘 I/O 的时间。这部分是我们调优的主战场。
- 排队延迟：请求在队列里等待的时间。高并发时，这个延迟往往最大。
我记得有一次，我们排查一个延迟问题，发现 80% 的时间都花在了锁竞争上。优化了锁的粒度后，延迟直接降了一个数量级。嗯，这就是调优的魅力。
1.3.2 吞吐量（Throughput）
吞吐量，就是「单位时间能处理多少笔交易」。通常用 TPS（Transactions Per Second）来衡量。
延迟和吞吐量，其实是跷跷板的关系。你追求低延迟，往往要牺牲一些吞吐量；反过来，想提高吞吐量，延迟可能会上升。为什么？因为高吞吐意味着更多的并发，而并发会带来锁竞争、上下文切换等开销。
我在项目中常用的策略是：先保证延迟在可接受范围内，再尽可能提高吞吐量。毕竟，交易系统对延迟更敏感。
1.3.3 抖动（Jitter）
抖动，是很多人容易忽略的指标。它衡量的是延迟的稳定性——延迟的方差有多大。
举个例子：系统 A 的延迟稳定在 100 微秒，系统 B 的平均延迟也是 100 微秒，但有时会跳到 1 毫秒。虽然平均值一样，但系统 B 的抖动更大，实际表现更差。
为什么抖动这么重要？因为交易策略往往基于「确定性」来设计。如果延迟忽高忽低，策略的假设就站不住脚了。我见过一个团队，花了大半年优化平均延迟，结果抖动问题没解决，策略上线后依然亏损。
我的经验：调优时，我习惯先看 P99 延迟（即 99% 的请求延迟在多少以内），而不是只看平均值。因为平均值会掩盖抖动问题。
1.4 性能调优的全局观
很多人调优，上来就盯着代码优化。其实，这是典型的「只见树木，不见森林」。性能调优，需要从全局视角出发。
我画了一张图，帮你理解调优的全局架构：
从这张图你能看到，性能调优是分层进行的。从硬件到操作系统，再到中间件和应用层，每一层都有优化空间。而且，上层的问题，往往需要在下层找根因。
举个例子：应用层发现延迟高，你优化了代码，效果不明显。这时候，你可能需要看看操作系统层——是不是中断没绑对 CPU？或者硬件层——是不是内存通道没跑满？
我在项目中遇到过类似的情况：一个订单处理模块，延迟总是比预期高 20%。代码层面怎么优化都没用。后来排查发现，是 NUMA 架构下，内存分配在了远端节点。调整了内存亲和性后，问题迎刃而解。
调优全局观的核心原则：
- 先测量，后优化：没有数据，不要动手。用 perf、火焰图、eBPF 等工具先定位瓶颈。
- 从瓶颈入手：找到最慢的环节，优先优化它。优化了非瓶颈，等于白干。
- 分层排查：应用层问题 -> 中间件层 -> 操作系统层 -> 硬件层，逐层深入。
- 权衡取舍：延迟、吞吐、抖动、成本，不可能全都要。根据业务场景，找到平衡点。
1.5 小结：调优不是一锤子买卖
性能调优，说白了就是一个持续迭代的过程。没有「调一次，管一辈子」的好事。业务在变，数据在变，硬件也在变。你需要建立一套性能监控体系，持续跟踪指标，发现问题就及时优化。
我个人习惯，每个季度做一次全面的性能复盘。看看延迟有没有恶化，吞吐有没有瓶颈，抖动有没有变大。发现问题，就列入下个季度的优化计划。
嗯，这一章就聊到这里。记住：性能调优，全局观比技巧更重要。先看清全局，再动手优化，事半功倍。
我的建议：刚开始做调优的同学，别急着改代码。先花一周时间，把系统的性能指标摸清楚。画一张延迟分布图，看看 P50、P99、P999 分别是多少。有了数据，你才知道该往哪个方向使劲。