1. 课程导学与性能基准
性能调优不是凭感觉“加机器”或“改配置”，而是基于可量化的指标、可复现的模型和可对比的基准。本章作为全链路诊断的起点，首先定义支付系统最核心的性能指标，然后构建从客户端到数据库的全链路性能模型，最后给出性能基准测试的标准方法论。
1.1 支付系统核心性能指标
支付场景对性能的要求极为苛刻：一笔交易涉及账户扣减、风控校验、渠道对接、账务记账等多个环节，任何一环的延迟都会直接影响用户体验和资金安全。以下五个指标是衡量支付系统性能的黄金标准：
| 指标 | 全称 | 定义 | 支付系统典型阈值 |
|---|---|---|---|
| TPS | Transactions Per Second | 系统每秒成功处理的事务数（通常指完整业务事务） | 核心支付链路 ≥ 2000 TPS |
| QPS | Queries Per Second | 系统每秒处理的查询请求数（读接口） | 订单查询 ≥ 10000 QPS |
| RT | Response Time | 从请求发出到收到完整响应的耗时（单位：ms） | 支付下单 RT ≤ 200ms |
| TP99 | Top Percentile 99 | 99% 的请求耗时在此值以下，反映长尾延迟 | TP99 ≤ 500ms |
| 成功率 | Success Rate | 成功响应数 / 总请求数（排除超时、异常） | ≥ 99.99% |
面试高频追问：“TPS 和 QPS 在支付系统中如何区分？”——支付下单接口是 TPS（写事务），订单列表查询是 QPS（读请求）。压测时务必分开建模，混在一起会导致指标失真。
1.2 全链路性能模型
支付订单系统的性能瓶颈往往不在单一节点，而是贯穿整个请求链路。下图展示了从用户点击“支付”到数据库落盘的全链路节点与典型耗时分布：
1.3 性能基准测试方法论
基准测试（Benchmark）是性能调优的“度量尺”。没有基准，优化就是盲人摸象。支付系统的基准测试必须遵循以下标准化流程：
- 定义场景与负载模型：区分“正常业务流量”（日常峰值）和“极限压测流量”（双11/秒杀）。支付场景必须包含混合读写比例（通常写:读 = 3:7）。
- 准备测试数据：数据库预置千万级订单数据，缓存预热热点商户和用户信息。避免“冷启动”导致测试结果虚高。
- 选择压测工具：推荐 JMeter（脚本灵活）或 Locust（Python 生态）。支付接口必须模拟真实请求头、签名、幂等性参数。
- 执行阶梯加压：从 100 QPS 起步，每 30 秒增加 200 QPS，直到系统出现错误率 > 1% 或 TP99 超过 1000ms。记录拐点。
- 采集全链路指标：同时采集 JVM（GC 频率、堆内存）、操作系统（CPU、网络 IO）、数据库（慢查询、连接池）、中间件（Redis 命中率、MQ 积压）。
- 输出基准报告：至少包含以下表格内容：
| 压测阶段 | 目标 QPS | 实际 TPS | 平均 RT (ms) | TP99 (ms) | 错误率 | CPU 使用率 |
|---|---|---|---|---|---|---|
| 阶段1 | 500 | 480 | 45 | 120 | 0.01% | 35% |
| 阶段2 | 1000 | 950 | 68 | 210 | 0.02% | 52% |
| 阶段3 | 2000 | 1820 | 112 | 380 | 0.05% | 78% |
| 阶段4（拐点） | 3000 | 2100 | 245 | 890 | 1.2% | 95% |
实战避坑：支付系统压测时务必开启“幂等性校验”和“风控降级”。很多团队压测时关闭了风控，上线后真实流量一进来，风控规则导致 RT 飙升 3 倍，TP99 直接突破 2s。基准测试的环境配置必须与生产环境一致。
1.4 性能模型与基准的关系
全链路性能模型告诉我们“瓶颈可能在哪里”，基准测试则告诉我们“现在到底有多差”。两者结合才能制定精准的优化目标：
- 目标设定：基于模型中的理论耗时，设定合理的 TP99 目标（例如支付下单 ≤ 500ms）。
- 差距分析：基准测试结果与目标对比，找出差距最大的环节（例如数据库耗时占 60%）。
- 迭代优化：每次优化后重新执行基准测试，验证是否缩小了差距。避免“优化了 A 却恶化了 B”。