一、性能调优概述：交易系统性能指标、调优目标与原则、方法论总览
1.1 交易系统的性能指标——到底该看什么？
做性能调优这么多年，我见过太多团队一上来就盯着「TPS」猛怼。其实，交易系统的性能指标远不止这一个。我个人习惯把指标分成三类：吞吐量、延迟、资源利用率。这三者就像三根柱子，缺一根都不稳。
| 指标类别 | 核心指标 | 说明 |
|---|---|---|
| 吞吐量 | TPS（每秒交易笔数） | 系统每秒能处理多少笔完整交易 |
| 延迟 | P50 / P99 / P999 延迟 | 50%、99%、99.9% 的交易在多少毫秒内完成 |
| 资源利用率 | CPU / 内存 / IO / 网络 | 各资源的使用率，判断瓶颈在哪 |
| 稳定性 | 错误率 / 超时率 | 交易失败或超时的比例 |
这里我想特别强调一下 P99 延迟。平均延迟有时候会骗人。我在项目中遇到过，平均延迟只有 20ms，但 P99 延迟飙到了 800ms。这意味着每 100 笔交易里，就有 1 笔用户要等将近 1 秒。在金融交易场景下，这 1 秒可能就是几百万的损失。
核心观点： 调优不是只看平均值，要看尾部延迟。P99 才是用户体验的真相。
1.2 调优目标与原则——别把系统调崩了
调优的目标说白了就一句话：在满足业务 SLA 的前提下，用最少的资源跑出最高的性能。但这里有个坑——很多人调着调着就把系统调崩了。
我总结了几条原则，这些年一直贴在工位上：
- 先测量，后优化。 没有数据支撑的调优都是瞎猜。我曾经见过一个团队，觉得「数据库连接池太小」，直接翻了三倍，结果把数据库打挂了。嗯，这就是没看监控的后果。
- 一次只改一个变量。 你同时改了线程池大小、缓存策略、SQL 索引，然后性能提升了 30%。请问，你知道是哪一步起了作用吗？不知道。所以，一次只动一个地方。
- 可回滚。 每次调优都要能快速回退。我习惯在代码里埋一个「配置开关」，线上调优时先切一小部分流量验证，没问题再全量。
- 不要过度优化。 你想想看，一个接口的 P99 延迟从 50ms 降到 45ms，花了你三天时间。这三天如果用来修一个 bug，可能收益更大。调优要算投入产出比。
避坑指南： 我曾经在凌晨三点上线了一个「优化版」的线程池配置，结果第二天早上交易队列堵死了。原因很简单——我忘了考虑业务高峰期的流量模型。从那以后，我所有的调优都必须在压测环境先跑一遍。
1.3 方法论总览——调优的「四步走」
调优不是玄学，它有一套成熟的方法论。我把它拆成四个步骤，你可以把它当成一个循环：
- 定义目标 —— 明确你要优化什么指标，目标值是多少。比如「P99 延迟从 200ms 降到 100ms」。
- 建立基线 —— 先跑一遍压测，记录当前的各项指标。没有基线，你根本不知道优化了多少。
- 定位瓶颈 —— 用工具（如 perf、火焰图、APM）找到最慢的那个环节。记住，优化一个非瓶颈点，等于没优化。
- 实施优化 —— 针对瓶颈做改动，然后回到第 2 步，重新压测验证。
下面这张图是我自己画的，把整个方法论串起来了：
这个循环看起来简单，但真正执行起来，很多人会卡在「定位瓶颈」这一步。为什么？因为瓶颈可能不在你直觉认为的地方。我遇到过最离谱的一次，系统慢不是因为数据库，而是因为日志框架在同步刷盘。你想想看，谁会第一时间怀疑日志呢？
我的小技巧： 定位瓶颈时，先看「资源利用率」这张表。如果 CPU 只有 20%，但 TPS 已经上不去了，那大概率是 IO 或锁的问题。如果 CPU 跑到了 90% 以上，那可能是计算密集或代码效率问题。方向对了，调优就成功了一半。
1.4 本章小结
这一章我们聊了三个东西：看什么指标、守什么原则、走什么流程。指标是眼睛，原则是底线，流程是地图。三者缺一不可。
我个人觉得，调优最难的不是技术，而是「克制」。克制住想改代码的冲动，先去看数据；克制住想一步到位的贪心，一次只改一个地方。能做到这两点，你已经比 80% 的工程师强了。