理解并发与吞吐：并发用户数、响应时间、吞吐量三者的关系、Little's Law 定律详解
做压测这么多年，我见过太多人一上来就问「系统能支持多少并发？」。说实话，这个问题本身就有问题。你问的「并发」到底指什么？是同时在线人数？还是每秒发起的请求数？这两个概念差了十万八千里。
这一章，咱们把并发、吞吐、响应时间这三个核心概念彻底掰扯清楚。尤其是 Little's Law，它就像压测界的勾股定理——简单，但能解决很多实际问题。
3.1 三个核心概念的定义
先给个最直白的定义，方便你理解。
| 术语 | 英文 | 一句话解释 |
|---|---|---|
| 并发用户数 | Concurrent Users | 同一时刻，系统内正在处理中的用户数量 |
| 响应时间 | Response Time | 从用户发出请求到收到完整响应所花的时间 |
| 吞吐量 | Throughput | 单位时间内系统处理的请求数量（通常用 TPS/QPS） |
嗯，这里要注意：并发用户数 ≠ 每秒请求数。很多人把这两个混为一谈，结果压测结果完全没法看。
关键区别：
- 并发用户数 = 系统里同时「待着」的用户数（就像餐厅里正在吃饭的客人）
- TPS = 每秒钟「完成」的请求数（就像厨师每秒钟端出的菜）
3.2 三者的关系：一个餐厅的比喻
我习惯用餐厅来类比这三个概念。你想想看：
- 并发用户数 = 餐厅里正在吃饭的客人数量
- 响应时间 = 每个客人从点菜到吃完离开的时间
- 吞吐量 = 餐厅每小时的翻台率（或者每小时的出菜数）
假设餐厅有 10 张桌子，每桌客人吃 1 小时。那么并发用户数就是 10（10 桌客人同时吃饭），吞吐量就是 10 桌/小时。如果每桌客人吃 30 分钟，并发用户数还是 10，但吞吐量变成了 20 桌/小时。
为什么会这样？因为响应时间变了。这就是三者最朴素的关系：并发用户数 = 吞吐量 × 响应时间。
3.3 Little's Law：压测界的基石
上面那个公式，就是大名鼎鼎的 Little's Law。它由 John Little 在 1961 年提出，适用于任何稳定的系统。
Little's Law 公式：
L = λ × W
- L = 系统中的平均请求数（并发用户数）
- λ = 平均到达率（吞吐量，TPS）
- W = 平均服务时间（响应时间）
我在项目中遇到过好几次这样的情况：开发说「系统能支持 1000 并发」，结果一压测，TPS 只有 200，响应时间却飙到了 5 秒。用 Little's Law 一算：1000 = 200 × 5，完全吻合。问题出在哪？响应时间太长，导致并发用户数虚高。
避坑指南：我曾经犯过一个低级错误——用 Little's Law 去算非稳态系统的数据。系统正在重启、缓存正在预热、或者有突发流量时，这个公式不成立。一定要等系统稳定后再采样。
3.4 三者的动态关系：一张图看懂
下面这张图展示了并发用户数、响应时间和吞吐量之间的动态关系。我建议你仔细看看，尤其是「拐点」的位置。
从图上可以清楚看到：
- 线性区：并发用户数增加，吞吐量同步上升，响应时间基本不变。这是系统的正常工作区间。
- 拐点：系统资源开始吃紧（比如 CPU 100%、数据库连接池耗尽）。
- 饱和区：再增加并发用户数，吞吐量不再增长，响应时间急剧上升。这就是「系统挂了」的前兆。
3.5 如何用 Little's Law 指导压测
知道了公式，怎么用？我给你三个实战场景。
场景一：估算需要的并发用户数
假设目标 TPS 是 1000，预期响应时间是 0.5 秒。那么需要的并发用户数：
L = λ × W = 1000 × 0.5 = 500也就是说，你需要模拟 500 个并发用户才能达到 1000 TPS 的目标。
场景二：验证压测结果是否合理
压测结束后，你得到三组数据：并发用户数 200，TPS 800，响应时间 0.3 秒。用公式验证：
200 ≈ 800 × 0.3 = 240嗯，240 和 200 有偏差。说明系统可能还没稳定，或者采样周期内存在波动。我建议你多跑几轮，取平均值。
场景三：定位性能瓶颈
如果并发用户数增加 20%，响应时间却增加了 100%，说明系统已经进入饱和区。这时候别盲目加并发，先找瓶颈在哪。
我的习惯：每次压测前，先用 Little's Law 算一个理论值。压测结束后，把实际值和理论值对比。偏差超过 20% 的，一定有问题——要么数据不准，要么系统不稳定。
3.6 常见误区与避坑
做压测这些年，我踩过不少坑。挑几个典型的说说。
- 误区一：并发用户数越高越好
其实不是。并发用户数只是手段，吞吐量才是目标。盲目增加并发，只会让响应时间变长，用户体验变差。 - 误区二：响应时间取平均值就够了
我见过一个系统，平均响应时间 200ms，但 99 分位响应时间 5 秒。平均值掩盖了长尾问题。一定要关注 P95、P99。 - 误区三：Little's Law 可以算任何场景
不行。它只适用于稳态系统。系统刚启动、缓存未预热、或者有突发流量时，算出来的结果没有意义。
避坑指南：我曾经在一个电商大促压测中，直接用 Little's Law 算并发用户数，结果压测时系统直接挂了。后来发现，大促流量是突发性的，不是稳态。对于这种场景，要用「峰值并发」而不是「平均并发」来设计压测方案。
3.7 小结
这一章的内容，说白了就是三个数字和一个公式：并发用户数、响应时间、吞吐量，以及 Little's Law（L = λ × W）。
记住三点：
- 三者是动态平衡的，一个变了，另外两个也会跟着变。
- 拐点之前是健康区，拐点之后是过载区。
- Little's Law 是压测的基石，但只适用于稳态系统。
下次做压测，先问自己三个问题：目标 TPS 是多少？预期响应时间是多少？需要多少并发用户数？用 Little's Law 算一遍，心里就有底了。