支付系统的性能直接影响用户体验、交易转化率和业务收入。研究表明，支付页面加载时间每增加1秒，转化率下降约7%；每100ms的延迟增加，会导致营收下降约1%。对于跨境支付系统而言，性能还受到地理距离、监管差异、多币种结算等多重因素影响，优化挑战更为复杂。
本文将系统性地覆盖支付性能优化的各个层面，从指标体系到具体技术方案，再到真实案例，帮助你构建高性能、高可用的支付系统。
优化任何系统之前，首先需要建立可衡量、可比较的性能指标。支付系统的核心性能指标包括以下几类。
延迟是单个请求从发出到收到完整响应所花费的时间，通常在不同分位值上衡量。
| 分位值 | 含义 | 典型支付系统目标 |
|---|---|---|
| P50（中位数） | 50%的请求在此时间内完成 | < 200ms |
| P90 | 90%的请求在此时间内完成 | < 500ms |
| P95 | 95%的请求在此时间内完成 | < 800ms |
| P99 | 99%的请求在此时间内完成 | < 2s |
| P99.9 | 99.9%的请求在此时间内完成 | < 5s |
为什么关注P99而非平均值？ 假设有100笔交易，99笔耗时100ms，1笔耗时10s。平均值为 (99 × 0.1 + 10) / 100 = 0.199s，看似不错。但P99 = 10s，意味着1%的用户经历了10秒的等待，这足以让用户流失。
吞吐量是系统单位时间内处理的交易数量，通常用 TPS（Transactions Per Second） 或 QPS（Queries Per Second） 表示。
| 系统规模 | 典型TPS目标 | 对应的日均交易量 |
|---|---|---|
| 小型（创业公司） | 100-500 TPS | 约860万-4300万/天 |
| 中型（区域性平台） | 1,000-5,000 TPS | 约8600万-4.3亿/天 |
| 大型（全国性支付） | 10,000-50,000 TPS | 约8.6亿-43亿/天 |
| 超大规模（支付宝/微信） | 100,000-500,000 TPS | 峰值可达100万+ TPS |
吞吐量与延迟的关系：吞吐量增加时，延迟也会逐渐上升。通常以系统在延迟目标（如P99 < 2s）内的最大吞吐量作为容量上限。
并发数是系统同时处理的请求数量。根据Little's Law：
其中：
示例：若系统每秒处理2000笔交易（），平均处理时间100ms（），则：
即系统平均需要同时处理200个请求。
| 指标 | 定义 | 优化目标 |
|---|---|---|
| 支付成功率 | 成功交易 / 总交易数 | > 99.5% |
| 网关可用性 | 网关正常响应时间占比 | > 99.99%（全年<53分钟宕机） |
| 幂等成功率 | 重复请求正确处理的比率 | 100% |
| 指标类别 | 具体指标 | 告警阈值 | 严重告警阈值 |
|---|---|---|---|
| 延迟 | P99支付耗时 | > 2s | > 5s |
| 吞吐量 | TPS | 低于高峰期的70% | 低于50% |
| 错误率 | 5xx错误率 | > 0.1% | > 1% |
| 超时率 | 渠道超时率 | > 1% | > 5% |
| 缓存 | 缓存命中率 | < 85% | < 70% |
| 数据库 | 慢查询数 | > 10/min | > 50/min |
| 连接池 | 池使用率 | > 80% | > 95% |
支付系统的网络通信贯穿整个交易链路：用户端 → CDN → 网关 → 内部服务 → 渠道方。每个网络跳转都引入延迟，优化需要全局考虑。
对于跨境支付系统，光速限制是物理瓶颈。光在光纤中的传播速度约为每秒20万公里：
| 地理距离 | 理论最小RTT | 实际RTT（含路由开销） |
|---|---|---|
| 上海 → 北京（1,200km） | 12ms | 25-35ms |
| 上海 → 新加坡（3,800km） | 38ms | 70-90ms |
| 上海 → 伦敦（9,200km） | 92ms | 180-250ms |
| 上海 → 纽约（12,000km） | 120ms | 220-300ms |
解决方案：在全球主要金融中心部署应用节点：
用户（东南亚） → 新加坡 PoP → 本地核心
用户（欧洲） → 法兰克福 PoP → 本地核心
用户（北美） → 弗吉尼亚 PoP → 本地核心
|
▼
全球分布式数据库（跨区域同步）
具体成本收益：假设一个欧洲用户在无本地节点时需要300ms完成支付，部署法兰克福节点后降至50ms，转化率预计提升约10-15%。
| 方案 | 原理 | 适用场景 | 切换速度 |
|---|---|---|---|
| BGP Anycast | 同一IP从多地点宣告，路由自动到最近节点 | API端点、DNS服务器 | < 1分钟 |
| GeoDNS | 根据用户IP返回最近节点 | Web页面、静态资源 | TTL依赖（通常1-5分钟） |
| 两者结合 | Anycast做TCP层，GeoDNS做HTTP层分流 | 大型全球部署 | 秒级 |
对于关键的渠道方对接（银行、卡组织），专线是降低延迟和抖动的最佳方案。
| 连接方式 | 延迟（上海→香港） | 月费（估算） | 可用性 | 适用场景 |
|---|---|---|---|---|
| 公网Internet | 40-200ms（有抖动） | 免费 | 99.0% | 非关键渠道 |
| IPsec VPN | 35-60ms | ¥5,000-15,000 | 99.5% | 中等SLA要求 |
| MPLS专线 | 20-30ms | ¥20,000-80,000 | 99.95% | 核心银行对接 |
| 多云直连 | 15-25ms | ¥10,000-30,000 | 99.9% | 云间数据同步 |
示例：上海到纽约链路，带宽200Mbps，RTT 250ms。
BDP = 200Mbps × 0.25s = 50Mb = 6.25MB
因此TCP接收窗口至少应设为6.25MB。
支付系统必须使用TLS加密，但握手延迟显著：
| 优化措施 | 减少的延迟 | 原理 |
|---|---|---|
| TLS 1.3 | 减少1-RTT | 1-RTT握手(TLS 1.3) vs 2-RTT(TLS 1.2) |
| 会话复用 | 减少1-RTT | 复用之前协商的会话密钥 |
| False Start | 减少0.5-RTT | 握手未完成时即发送应用数据 |
| OCSP Stapling | 减少DNS查询 | 服务端主动提供证书状态 |
| 连接复用（HTTP/2+） | 消除多次握手 | 长连接复用 |
综合效果：应用上述所有优化后，TLS建立时间从约300ms降至约30ms。
支付核心链路上的关键操作，如风控检查、余额更新、通知发送等，需要合理设计同步/异步边界。
同步处理（用户必须等待）：
用户 → 网关API → 验证 → 风控评分 → 渠道提交 → 响应回用户
↓ 必须同步，用户在等待 ↑
异步处理（用户无需等待）：
用户 ← 网关API（"受理成功"）
|
▼
消息队列 ──→ 风控异步审核
──→ 会计记账
──→ 通知发送
──→ 对账处理
同步与异步的决策矩阵：
| 操作 | 同步/异步 | 原因 | 用户期望等待时间 |
|---|---|---|---|
| 支付请求提交 | 同步 | 用户需要知道是否成功 | < 3秒 |
| 风控评分 | 同步（基础分）+ 异步（深度分） | 基础分毫秒级，深度分秒级 | < 200ms |
| 余额更新 | 同步 | CAP理论中的数据一致性要求 | < 100ms |
| 会计记账 | 异步 | 不阻塞用户，最终一致性可接受 | - |
| 通知推送 | 异步 | 不阻塞交易 | - |
| 对账处理 | 异步（定时任务） | 按天/小时执行 | - |
对数据库、Redis、渠道HTTP接口的连接池优化是见效最快的措施之一。
连接池参数优化建议：
| 连接池 | 最小连接数 | 最大连接数 | 获取超时 | 最大等待队列 |
|---|---|---|---|---|
| 数据库写池 | 10 | 50 | 500ms | 100 |
| 数据库读池 | 20 | 100 | 200ms | 200 |
| Redis | 10 | 30 | 200ms | 50 |
| HTTP渠道池 | 5 | 20 | 3s | 50 |
计算公式：最大连接数 = 预期TPS × P99单请求耗时 × 安全系数
示例：预期TPS = 2000，P99数据库查询耗时取50ms，安全系数取1.5：
高TPS下，GC是Java/C#支付系统的常见性能瓶颈。
| 优化手段 | 效果 | 实现方式 |
|---|---|---|
| 对象池化 | 减少对象创建次数 | 复用DTO、Buffer、Connection |
| 值类型 | 避免装箱拆箱 | 使用原始类型而非包装类 |
| ThreadLocal | 避免线程安全的锁竞争 | 缓存SimpleDateFormat等 |
| 零拷贝 | 减少数据复制 | DirectBuffer、FileChannel |
| 预编译SQL | 减少SQL解析开销 | 使用PreparedStatement并缓存 |
GC优化实例：某支付网关在TPS 5000时，GC暂停时间从150ms优化至12ms，通过：
-XX:MaxGCPauseMillis=20支付渠道的失败响应通常较慢（超时），设置合理的超时时间至关重要。
| 场景 | 超时设置 | 熔断阈值 | 半开时间 |
|---|---|---|---|
| 内部服务调用 | 500ms | 50%错误率/10s | 5s |
| 渠道HTTP调用 | 3s | 30%错误率/30s | 10s |
| 数据库查询 | 200ms | 20个慢查询/1min | - |
| Redis操作 | 100ms | 20%超时率/10s | 3s |
熔断模式：
正常状态 ──→ 失败次数/比例超过阈值 ──→ 熔断(Open)
↑ ↓
└────── 超时后，半开(Half-Open) ←─────┘
│
├── 请求成功 → 关闭(Closed)
└── 请求失败 → 继续熔断(Open)
缓存是支付系统性能优化的核心手段。合理的缓存策略能将热点数据的访问延迟从毫秒级降至微秒级。
第1层：L1本地缓存（Caffeine/Caffeine）
延迟：< 1μs | 容量：MB级别 | 时效：秒级
↓ 缓存未命中时
第2层：L2分布式缓存（Redis）
延迟：< 5ms | 容量：GB级别 | 时效：分钟级
↓ 缓存未命中时
第3层：数据库
延迟：10-50ms | 容量：TB级别 | 强一致性
命中率对性能的影响分析：
假设1000 QPS，各层延迟如上：
| L1命中率 | L2命中率 | 穿透率 | 平均响应时间 |
|---|---|---|---|
| 0% | 80% | 20% | 0 + 0.8×5 + 0.2×30 = 10ms |
| 50% | 80%（剩余） | 10% | 0.5×0.001 + 0.5×0.8×5 + 0.1×30 ≈ 5ms |
| 80% | 80%（剩余） | 4% | 0.8×0.001 + 0.16×5 + 0.04×30 ≈ 2ms |
| 95% | 80%（剩余） | 1% | 0.95×0.001 + 0.04×5 + 0.01×30 ≈ 0.5ms |
| 缓存对象 | 数据类型 | TTL | 更新策略 | 预期命中率 |
|---|---|---|---|---|
| 商户配置 | JSON/Proto | 1min | 主动刷新 | > 99% |
| 汇率表 | 浮点数数组 | 5s | 轮询更新 | > 95% |
| BIN表 | KV映射 | 1h | 懒惰加载 | > 90% |
| 风控规则 | DSL脚本 | 5min | 版本对比 | > 99% |
| 渠道路由 | 排序列表 | 10s | 事件驱动 | > 95% |
| 用户Session | JSON | 30min | 写入时更新 | > 70% |
| 幂等令牌 | 布尔值 | 24h | 写入时设置 | 100%（必须） |
缓存与数据库的一致性是分布式系统的经典难题。
方案一：Cache-Aside（旁路缓存） — 支付系统最常用
读操作：
1. 查询缓存 → 命中则返回
2. 未命中 → 查询数据库 → 写入缓存（带TTL） → 返回
写操作：
1. 更新数据库
2. 删除缓存（淘汰而非更新）
方案二：Read-Through + Write-Through
读操作：
→ 缓存层自动加载（透明）
写操作：
→ 先写缓存 → 缓存同步写入数据库
方案三：最终一致 + 补偿
适用于汇率、渠道状态等允许短暂不一致的数据：
1. 定时任务从数据库加载最新数据到缓存
2. 变更发生时推送消息到缓存更新队列
3. 缓存通过版本号比对避免覆盖更新
缓存一致性对比：
| 方案 | 一致性 | 延迟 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| Cache-Aside + 淘汰 | 最终一致 | 低 | 低 | 商户配置、BIN表 |
| Write-Through | 强一致 | 中等 | 中 | 幂等令牌、余额 |
| 读写穿透（Read/Write Through） | 强一致 | 中等 | 高 | 需要透明缓存的场景 |
| TTL过期 | 最终一致 | 最低 | 最低 | 汇率、渠道状态 |
使用Pipeline批量操作：将N次命令合并为一次网络往返
合理选择数据结构：
| 场景 | 推荐结构 | 原因 |
|---|---|---|
| 商户配置 | Hash | 可单独读写某个字段 |
| 计数器 | String + INCR | 原子自增，无需锁 |
| 排行榜 | Sorted Set | 天然支持排序 |
| 限流桶 | List + Lua | 原子性操作 |
| 分布式锁 | String + Lua + RedLock | 互斥+容错 |
避免大Key：
热点Key处理：
支付系统的数据库面临高并发写入、强一致性要求、历史数据庞大三重挑战。
水平拆分策略：
| 分片键 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 商户ID | 同一商户数据集中 | 大商户数据倾斜 | 商户间查询隔离 |
| 用户ID | 同一用户数据集中 | 跨用户查询困难 | 用户查询为主 |
| 交易ID | 分布均匀 | 关联查询需广播 | 纯交易记录 |
| 时间 | 容易归档 | 热点集中在最新分区 | 日志、历史数据 |
分片估算：
假设日均交易100万笔，保留3年数据，每笔记录约2KB：
若每张表包含1000万记录，需要：
建议分片数为2的幂次，便于扩缩容：128片（2^7 = 128）。
主库（Write）
/ | \
/ | \
读库1 读库2 读库3
(只读) (只读) (只读)
延迟问题处理：主从延迟可能导致写入后立即读取不到数据。
| 业务场景 | 解决方案 | 实现方式 |
|---|---|---|
| 支付成功后查状态 | 强制读主库 | 根据是否有未同步写标记路由 |
| 对账查询 | 读从库 | 允许最终一致性 |
| 近实时监控 | 读从库 + 延迟补偿 | 接受1-2秒延迟 |
支付系统的核心索引设计：
-- 交易主表索引
CREATE INDEX idx_trade_order_no ON payment_orders(order_no);
CREATE INDEX idx_trade_merchant_id ON payment_orders(merchant_id, create_time);
CREATE INDEX idx_trade_status ON payment_orders(status, create_time);
CREATE INDEX idx_trade_user_id ON payment_orders(user_id, create_time);
-- 对账表索引
CREATE INDEX idx_reconciliation_date ON reconciliation(date, merchant_id);
CREATE INDEX idx_reconciliation_status ON reconciliation(status);
-- 渠道流水表索引
CREATE INDEX idx_channel_transaction ON channel_transactions(
channel_code, transaction_id
);
索引优化效果：
| 查询场景 | 无索引 | 全表扫描时间 | 索引优化后 | 提升倍数 |
|---|---|---|---|---|
| 按订单号查询 | ❌ | 约800ms（1000万行） | < 1ms | > 800x |
| 商户统计今日交易 | ❌ | 约300ms | < 5ms | > 60x |
| 对账查询未匹配记录 | ❌ | 约3s | < 50ms | > 60x |
复合索引最左前缀原则：idx_merchant_time(merchant_id, create_time) 能加速以下查询：
WHERE merchant_id = 'M001'WHERE merchant_id = 'M001' AND create_time >= '2026-01-01'WHERE create_time >= '2026-01-01'（无法使用，跳过了最左列）治理流程：
常见慢查询及优化：
| 问题SQL | 问题 | 优化方案 | 优化前 | 优化后 |
|---|---|---|---|---|
SELECT COUNT(*) FROM orders WHERE ... |
大表全扫 | 使用计数器缓存 | 2s | 1ms |
SELECT * FROM orders ORDER BY create_time DESC LIMIT 10 OFFSET 1000000 |
深度分页 | 改用游标分页 | 3s | 5ms |
UPDATE orders SET status='paid' WHERE status='pending' |
大范围更新锁表 | 分批+索引 | 10s（锁等待） | 50ms |
JOIN 大表无索引 |
Nested Loop扫描 | 加复合索引 | 5s | 10ms |
| 优化项 | 优化前 | 优化后 | 效果 |
|---|---|---|---|
| 事务范围 | 整个请求（含网络IO） | 仅数据库写操作 | 锁持有时间减少90% |
| 隔离级别 | Serializable | Read Committed | 并发提升3倍 |
| 自动提交 | OFF（需手工提交） | ON（单条SQL自动提交） | 减少遗忘提交的风险 |
| PreparedStatement | SQL拼接 | 预编译+参数化 | 减少SQL解析 + 防注入 |
消息队列在支付系统中承担解耦、削峰填谷、异步处理的核心角色。
┌──→ 风控异步审核 ──→ 风控数据库
│
用户 → 网关API ──┼──→ 会计记账 ──→ 账务数据库
│
├──→ 通知发送 ──→ 推送服务
│
├──→ 对账准备 ──→ 对账系统
│
└──→ 数据审计 ──→ 数据仓库
| 特性 | Kafka | RabbitMQ | Pulsar | RocketMQ |
|---|---|---|---|---|
| 吞吐量 | 100万+/s | 10万/s | 100万+/s | 10万+/s |
| 延迟 | 2-5ms | <1ms | 5-10ms | 1-5ms |
| 消息可靠性 | 高（ACK机制） | 高 | 极高 | 高 |
| 消息顺序 | 分区内有序 | 队列有序 | 分片内有序 | 队列有序 |
| 死信队列 | 需手动实现 | 内置 | 内置 | 内置 |
| 运维复杂度 | 中等 | 低 | 高 | 中等 |
| 支付系统推荐度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
建议：支付系统核心链路选用 Kafka（高吞吐、持久化），对延迟敏感的通知类用 RabbitMQ。
批量写入数据库：
# ❌ 逐条插入（1000条 = 1000次网络往返）
for record in records:
db.insert(record)
# ✅ 批量插入（1000条 = 1次网络往返）
db.batch_insert(records, batch_size=500)
批量大小对性能的影响（以1000条记录为例）：
| 批量大小 | 网络往返次数 | 总耗时 | 内存开销 |
|---|---|---|---|
| 1（逐条） | 1000 | 约10s | 低 |
| 50 | 20 | 约300ms | 低 |
| 200 | 5 | 约120ms | 中 |
| 500 | 2 | 约80ms | 较高 |
| 1000 | 1 | 约60ms | 高（可能OOM） |
推荐：批量大小控制在200-500之间，平衡延迟和内存。
Topic: payment-events (10 partitions)
├── Partition 0 → Consumer 1 (处理消息 0, 10, 20...)
├── Partition 1 → Consumer 2 (处理消息 1, 11, 21...)
├── ...
└── Partition 9 → Consumer 10 (处理消息 9, 19, 29...)
关键公式：消费者数量 ≤ 分区数。同组内消费者超过分区数时，多余的消费者会空闲。
分区数估算：目标消费能力 = 单消费者处理速度 × 分区数 ≥ 生产速度
示例：生产者每秒推送5000条消息，单个消费者每秒处理800条。
考虑缓冲余量，建议分区数为10。
支付系统的流量天然存在高峰：
| 时段 | 典型交易量比例 | 相对基线的倍数 |
|---|---|---|
| 00:00-06:00（低谷） | 5% | 0.2x |
| 06:00-09:00（早高峰） | 15% | 0.6x |
| 09:00-12:00（办公） | 25% | 1.0x（基线） |
| 12:00-14:00（午休） | 15% | 0.6x |
| 14:00-18:00（下午） | 20% | 0.8x |
| 18:00-22:00（晚高峰） | 15% | 0.6x |
| 22:00-00:00（促销活动峰值） | 5% | 5-20x |
削峰策略：
限流算法对比：
| 算法 | 实现原理 | 优点 | 缺点 |
|---|---|---|---|
| 令牌桶 | 匀速产生令牌，消费需获取令牌 | 允许突发流量 | 实现稍复杂 |
| 漏桶 | 固定速率流出请求 | 输出完全平滑 | 不允许突发 |
| 滑动窗口 | 统计时间窗口内请求数 | 实现简单 | 窗口边界误差 |
| 自适应限流 | 根据系统负载动态调整 | 弹性好 | 实现复杂 |
令牌桶实现示例：
初始状态：桶中有100个令牌
每10ms补充1个令牌（100 TPS）
请求到达时：
- 桶中有令牌 → 消费1个，放行
- 桶中无令牌 → 拒绝或排队
突发场景：高峰期300 QPS，前100个请求立即通过，
剩余200个请求等待令牌补充（约2秒）
压测类型：
| 类型 | 目的 | 方法 | 目标 |
|---|---|---|---|
| 基准测试 | 建立基线 | 单接口逐步加压 | 获取基础TPS和延迟 |
| 负载测试 | 验证能否承载 | 按预期峰值加压 | TPS达标且延迟在阈值内 |
| 压力测试 | 找系统上限 | 持续加压直到系统崩溃 | 找到瓶颈点 |
| 稳定性测试 | 验证长期运行 | 70%负载持续24h+ | 无内存泄漏/OOM |
| 尖峰测试 | 验证弹性和恢复 | 突然2x流量冲击 | 自动伸缩恢复 |
压测工具对比：
| 工具 | 协议支持 | 最大并发 | 分布式支持 | 学习成本 |
|---|---|---|---|---|
| Locust | HTTP/gRPC | 10万+ | ✅ | 低（Python） |
| JMeter | HTTP/gRPC/DB/多协议 | 1万+ | ✅ | 中（GUI） |
| wrk2 | HTTP | 10万+ | ❌ | 低（Lua脚本） |
| Gatling | HTTP/WebSocket | 5万+ | ❌ | 中（Scala） |
| k6 | HTTP/gRPC/Browser | 10万+ | ✅ | 低（JS） |
定义场景：复制生产流量比例
建立基线：用最低并发压测，获取基础延迟
逐步加压：每次增加20%并发，观察延迟变化
找到拐点：延迟从线性增长转向指数增长的点即为系统上限
资源监控：同步监控CPU、内存、磁盘IO、网络、GC、连接池
典型压测输出：
并发数: 200 | TPS: 1800 | P99: 320ms | CPU: 45% | DB连接: 32/100
并发数: 400 | TPS: 3500 | P99: 380ms | CPU: 62% | DB连接: 55/100
并发数: 600 | TPS: 4800 | P99: 450ms | CPU: 78% | DB连接: 78/100
并发数: 800 | TPS: 5200 | P99: 920ms ← 拐点！CPU: 92% | DB连接: 98/100
并发数: 1000 | TPS: 5300 | P99: 2500ms ← 超限！CPU: 99% | 超时率: 5%
系统安全容量：TPS 4800（P99 < 500ms），建议预留30%余量，即实际容量约为3300 TPS。
预留容量计算：
| 参数 | 说明 | 建议值 |
|---|---|---|
| 预测峰值TPS | 基于历史数据和业务增长率 | 统计建模 |
| 增长预留 | 应对突发增长 | 30-50% |
| 冗余系数 | 应对宕机/流量重分配 | 20-30%（N+1） |
| 安全系数 | P99目标余量 | 20-30% |
示例：当前峰值2000 TPS，增长预留30%，N+1冗余：
即系统需要支撑约3100 TPS以上的能力。
用户端 ──→ CDN ──→ SLB ──→ API网关 ──→ 微服务 ──→ 数据库/缓存/渠道
↓ ↓ ↓ ↓ ↓ ↓
RUM CDN ALB APM Metrics DB/Persistence
(Lighthouse) (日志) (Trace) (Prometheus) (Slow Query)
| 维度 | 工具/技术 | 核心指标 |
|---|---|---|
| 用户体验 | Lighthouse, RUM | LCP、FID、CLS、首屏时间 |
| 应用性能 | APM（Pinpoint/SkyWalking） | 调用链、Span耗时、错误率 |
| 中间件 | Prometheus + Grafana | Redis/MQ/DB连接数、延迟、命中率 |
| 基础设施 | Node Exporter | CPU、内存、IO、网络 |
| 业务监控 | 自定义Metrics | TPS、成功率、退款率 |
| 日志分析 | ELK/Loki | 错误日志、慢日志、异常模式 |
延迟看板（按接口分组）：
接口 | P50 | P90 | P99 | P99.9 | TPS
-------------|--------|--------|--------|--------|-------
/payments | 85ms | 210ms | 450ms | 1200ms | 1800
/refunds | 65ms | 180ms | 350ms | 900ms | 120
/balance | 3ms | 8ms | 25ms | 80ms | 500
/reports | 500ms | 2s | 5s | 12s | 30
资源监控看板：
组件 | 当前使用率 | 告警阈值 | 状态
-----------|-----------|---------|------
API网关CPU | 62% | 80% | ✅
DB连接池 | 78/100 | 90 | ✅
Redis内存 | 3.2GB/8GB | 80% | ✅
MQ积压 | 150 | 5000 | ✅
| 现象 | 可能原因 | 诊断方法 | 快速修复 |
|---|---|---|---|
| 请求超时 | DB连接池耗尽 | 查看DB连接数、活跃连接数 | 扩大连接池 |
| 响应抖动 | GC暂停 | 查看GC日志、Young/Old区变化 | 调整GC参数 |
| TPS上不去 | 代码同步锁 | Thread dump查看锁等待 | 优化锁粒度 |
| 偶发超时 | 慢查询 | 慢查询日志、EXPLAIN | 加索引/改写SQL |
| 流量高峰失败 | 资源不足 | 查看CPU/内存/IO曲线 | 提前扩容 |
背景：东南亚跨境支付平台，日均交易50万笔，用户投诉支付慢。
分析发现：
| 问题 | 根因 | 影响 |
|---|---|---|
| 数据库连接池太小（20） | 只需调整参数 | 频繁等待获取连接 |
| 汇率查询每次实时计算 | 未缓存汇率 | 每次PAY请求额外100ms |
| 日志同步刷盘 | 配置问题 | IO等待占请求时间的30% |
| 无本地缓存 | 架构缺陷 | 90%的商户配置重复请求DB |
| 串行调用渠道 | 设计问题 | 4个渠道依次调用，总计800ms |
优化措施：
优化前后对比：
指标 | 优化前 | 优化后 | 提升
------------|---------|---------|------
P50 | 450ms | 85ms | 5.3x
P90 | 1200ms | 210ms | 5.7x
P99 | 2000ms | 180ms | 11.1x
TPS | 300 | 1800 | 6x
错误率 | 2.3% | 0.05% | 46x
背景：某支付系统为双11预热，压测发现TPS达到5000后陡然下降。
排查过程：
优化方案：
效果：TPS从5000飙升至50000（10倍），P99稳定在200ms以内。
背景：某跨境收款平台，商户提现操作需要先扣余额、再通知渠道、再记账、再通知商户——全部同步。
优化前流程：
用户 → 提现请求 → 扣余额(10ms)
→ 调用渠道(300ms)
→ 记账(20ms)
→ 通知商户(50ms)
→ 返回成功(5ms)
总计：385ms，TPS上限约2600
优化后流程：
用户 → 提现请求 → 扣余额(10ms) → 写入MQ → 返回成功(5ms)
总计：15ms
↓
MQ消费者
├── 调用渠道(300ms，异步)
├── 记账(20ms，采用批量)
└── 通知商户(50ms，异步批量)
效果：