一、吞吐优化概述
1.1 什么是吞吐量
吞吐量，说白了就是系统在单位时间内能处理多少活儿。
我习惯用这个公式来理解：
吞吐量 = 完成请求数 / 时间窗口举个例子。一个 Web 服务，1 秒钟处理了 1000 个请求，那它的吞吐量就是 1000 QPS（Queries Per Second）。
但这里有个坑——你得搞清楚「完成」是什么意思。请求发出去，响应没回来，那不算。只有完整走完整个生命周期的，才算数。
我在项目中遇到过一种情况：监控面板上显示 QPS 很高，但用户反馈说页面打不开。后来一查，原来是大量请求被直接拒绝了，根本没处理。嗯，这种「虚假吞吐」最害人。
常见的吞吐量指标有这些：
- QPS：每秒查询数，常用于 API 网关、数据库
- TPS：每秒事务数，常用于交易系统
- RPS：每秒请求数，和 QPS 类似但更通用
- 吞吐带宽：每秒传输的数据量，常用于 CDN、文件服务
核心观点：吞吐量不是越高越好，而是要在满足延迟要求的前提下，尽可能高。
1.2 为什么吞吐优化重要
你想想看，一个系统上线后，最怕什么？
怕用户一多就崩。怕双十一流量一来，服务器直接冒烟。怕老板问「能扛多少并发」时，你支支吾吾答不上来。
吞吐优化，就是为了解决这些问题。
我经历过一个真实案例。某电商平台，平时 QPS 也就 2000，但大促期间峰值能到 5 万。如果不做吞吐优化，那扩容成本会高得吓人。优化后，同样的机器数量，吞吐量翻了 3 倍。说白了，省下来的钱够给团队发一年奖金。
吞吐优化的重要性，可以归纳为三点：
- 降低成本：同样的硬件，处理更多请求
- 提升用户体验：系统不卡顿，用户不流失
- 增强系统韧性：能扛住突发流量，不容易雪崩
我的建议：别等到系统出问题了才做吞吐优化。在架构设计阶段，就应该把吞吐量作为一个核心指标来考量。
1.3 吞吐与延迟的关系
这是个老生常谈的话题，但很多人理解得不够深。
吞吐量和延迟，不是简单的反比关系。它们之间有个经典的曲线——拐点效应。
我来画个图帮你理解：
这张图我画了很多次，每次给团队讲吞吐优化时都会拿出来。你看：
- 线性区：请求少，延迟低且稳定。吞吐量增加，延迟几乎不变。
- 弯曲区：吞吐量继续增加，延迟开始缓慢上升。这是系统的「舒适区」。
- 过载区：一旦过了拐点，延迟会急剧飙升。系统开始排队、超时、甚至崩溃。
为什么会这样？
因为系统资源是有限的。CPU、内存、IO、网络连接，任何一个成为瓶颈，都会导致请求排队。排队越长，延迟越高。延迟越高，吞吐量反而上不去了。
我曾经优化过一个消息队列系统。刚开始时，生产者发消息很快，消费者处理也很快，吞吐量很漂亮。但某天突然发现，消费者延迟从 10ms 涨到了 500ms。一查，原来是磁盘 IO 到了极限。说白了，木桶效应在吞吐优化里体现得淋漓尽致。
注意：不要为了追求高吞吐而牺牲延迟。尤其是在实时性要求高的场景下（比如交易系统、直播互动），延迟超标就是事故。
1.4 优化目标设定
做吞吐优化，最忌讳的就是「拍脑袋」。我见过太多团队，上来就说「我们要把 QPS 提升到 10 万」，结果连当前是多少都不知道。
设定优化目标，我建议分三步走：
第一步：摸清家底
先搞清楚当前系统的吞吐量是多少。用压测工具（比如 wrk、JMeter、Locust）跑一跑，拿到基线数据。
# 用 wrk 做简单压测
wrk -t12 -c400 -d30s http://your-api.com/endpoint
# 输出示例
Running 30s test @ http://your-api.com/endpoint
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 45.67ms 12.34ms 200.00ms 85.00%
Req/Sec 8,500 1,200 12,000 75.00%
305,000 requests in 30.00s, 45.00MB read
Requests/sec: 10,166.67
Transfer/sec: 1.50MB第二步：确定目标
目标要符合 SMART 原则。别定那种「提升吞吐量」的模糊目标，要具体到数字。
| 目标类型 | 错误示例 | 正确示例 |
|---|---|---|
| 吞吐量 | 提升系统性能 | QPS 从 1 万提升到 3 万 |
| 延迟 | 让系统更快 | P99 延迟从 200ms 降到 50ms |
| 资源消耗 | 节省资源 | 同等吞吐下 CPU 使用率降低 30% |
第三步：设定红线
优化吞吐量时，一定要设定延迟红线。比如：
- P99 延迟不得超过 100ms
- 错误率不得超过 0.1%
- CPU 使用率不得超过 80%
我曾经犯过一个错误。优化一个缓存系统时，我把吞吐量从 5 万 QPS 提升到了 8 万，但没注意延迟。结果上线后，P99 延迟从 20ms 飙到了 500ms。用户投诉如潮水般涌来。嗯，从那以后，我再也不敢只看吞吐量了。
总结一下：吞吐优化的目标，不是「跑得最快」，而是「在可接受的延迟范围内，跑得最多」。
一个小技巧：设定目标时，可以留 20% 的余量。比如业务要求 1 万 QPS，你按 1.2 万来优化。这样即使有突发流量，系统也能扛得住。
好了，这一章就聊到这儿。吞吐优化是个系统工程，后面我们会一步步深入。记住一句话：没有测量，就没有优化。先拿到基线数据，再谈优化目标。