1. 从TPS 100到10000：一次性能优化的实战复盘
"老板，之前咱TPS是100，我优化完是10000"——这句话最近在技术圈疯传。作为一个经历过类似场景的老兵，我完全理解这种优化带来的成就感。但更值得分享的是，从三位数到五位数的跨越，中间到底发生了什么？今天我就用真实案例，拆解这个百倍性能提升背后的完整逻辑链。
TPS（Transactions Per Second）是衡量系统吞吐量的黄金指标，它直接关系到用户体验和商业收益。当你的电商系统在秒杀活动中从100TPS暴跌到个位数，或是支付网关在促销日卡在200TPS上不去时，这种优化就变成了救火行动。但不同于简单的"加机器"思路，真正的性能优化需要精准的问题定位和系统的解决方案。
2. 性能优化的黄金法则：从测量开始
2.1 建立基准测试环境
在开始任何优化前，必须建立可重复的测试基准。我通常会搭建与生产环境1:1的压测环境，使用JMeter配置阶梯式压力模型。关键配置包括：
- 线程组设计：采用50/100/150的阶梯递增
- 断言设置：响应时间>2s即为失败
- 监听器配置：务必勾选"聚合报告"和"响应时间图"
重要提示：绝对不要在办公网络执行压测！我曾见过因为内网交换机瓶颈导致的"假性低TPS"，白白浪费两天排查时间。建议直接使用云厂商的压测服务或独立物理机。
2.2 关键指标监控矩阵
真正的性能工程师不会只盯着TPS数字。我的监控看板永远包含这五个维度：
| 指标类别 | 监控项 | 预警阈值 | 工具链 |
|---|---|---|---|
| 系统资源 | CPU利用率/load average | >70%持续5分钟 | Prometheus |
| 中间件 | 数据库活跃连接数 | >最大连接数80% | Grafana+Dashboard |
| 应用层 | JVM GC频率 | YoungGC>2次/秒 | Arthas |
| 网络 | TCP重传率 | >1% | iftop+netstat |
| 业务指标 | 错误码429出现频率 | >1%请求量 | 自定义埋点 |
3. 典型瓶颈定位与破解之道
3.1 数据库：最隐蔽的性能杀手
在一次物流系统优化中，我们发现TPS卡在150左右。通过Arthas的trace命令，定位到90%的耗时发生在SQL查询。进一步分析发现：
-- 问题SQL（执行时间1.2s） SELECT * FROM orders WHERE status IN ('paid','shipped') AND create_time > '2023-01-01' ORDER BY update_time DESC; -- 优化后（执行时间0.02s） SELECT id,order_no FROM orders WHERE status = 'paid' AND create_time > '2023-01-01' UNION ALL SELECT id,order_no FROM orders WHERE status = 'shipped' AND create_time > '2023-01-01' ORDER BY update_time DESC LIMIT 1000;优化点解析：
- 拆解IN查询为UNION ALL，让优化器能使用status索引
- 只查询必要字段减少I/O
- 添加LIMIT避免全表扫描
3.2 线程阻塞：并发场景的隐形陷阱
某金融系统在TPS达到300时出现断崖式下跌。通过jstack获取线程dump，发现大量线程阻塞在：
"http-nio-8080-exec-5" #20 daemon prio=5 os_prio=0 tid=0x00007f48740f6800 nid=0x4e1f waiting for monitor entry [0x00007f486b7fe000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.service.PaymentService.lockAccount(PaymentService.java:112) - waiting to lock <0x00000000f5d1b2c0> (a java.lang.Object)解决方案：
- 用StampedLock替代synchronized
- 引入分段锁，将账户ID哈希到16个锁槽
- 设置锁等待超时（300ms自动放弃）
4. 进阶优化：从千到万的质变
4.1 缓存策略的降维打击
当基础优化完成后，要实现TPS的指数级提升必须重构数据流向。我们在社交APP消息系统中实施了三层缓存：
- 本地缓存：使用Caffeine实现LRU缓存，TTL=5s
- 分布式缓存：Redis集群+Redisson客户端，TTL=30s
- 异步写回：RocketMQ消费binlog异步更新缓存
关键配置参数：
Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5, TimeUnit.SECONDS) .recordStats() .build();4.2 流量整形与异步化改造
对于秒杀类场景，我们设计了分级处理管道：
用户请求 → 限流层(Guava RateLimiter) → 内存队列(Disruptor RingBuffer) → 工作线程池(自定义RejectedExecutionHandler) → 批量提交(HikariCP batch模式)性能对比：
- 同步模式：TPS 1200，平均RT 800ms
- 异步模式：TPS 9500，平均RT 120ms
5. 性能优化的黑暗面：那些容易翻车的细节
5.1 过度优化的反模式
在一次过度追求TPS的过程中，我们曾犯过这些错误：
- 将所有SQL都改为异步执行 → 导致数据不一致
- 关闭所有WAL日志 → 故障时丢失15分钟数据
- 线程池设为Integer.MAX_VALUE → OOM杀死整个容器
5.2 压测数据的可信度验证
务必检查这些JMeter陷阱：
- 是否开启了"Keep-Alive"？关闭会导致TCP连接重建开销
- Think Time设置是否合理？0思考时间会制造虚假压力
- 断言过于严格可能误判成功请求
我曾遇到过一个诡异案例：测试环境的TPS是生产环境的3倍。最终发现是因为测试机的/etc/hosts没有配置域名解析，直接走本地回环，跳过了网络层瓶颈。
