一、并发瓶颈概述：什么是并发瓶颈、常见表现与抓包定位原理

大家好，我是老赵。做后端十几年，我见过太多系统在流量高峰时突然“趴窝”的场景。今天咱们聊聊并发瓶颈——这玩意儿说白了，就是系统处理不过来那么多同时来的请求了。

你想想看，一个接口平时响应 50ms，突然变成 5 秒；一个服务平时 CPU 占用 30%，高峰期直接飙到 99%。嗯，这就是并发瓶颈在作祟。

1.1 什么是并发瓶颈

并发瓶颈，指的是系统在同时处理大量请求时，某个或某些资源达到极限，导致整体吞吐量上不去、响应时间急剧恶化。

我个人习惯把并发瓶颈分成三类：

我在项目中遇到过最典型的例子：一个订单查询接口，单机 QPS 到 200 就上不去了。查了半天，发现是数据库连接池只有 20 个，高峰期所有线程都在等连接。这就是典型的资源竞争型瓶颈。

1.2 并发瓶颈的常见表现

并发瓶颈不会凭空出现，它总会留下一些“症状”。我总结了几个最常见的信号：

• 响应时间陡增：平时 100ms 的接口，高峰期变成 3 秒、5 秒甚至超时。这不是线性增长，而是断崖式恶化。
• 吞吐量上不去：加机器、加线程，QPS 就是不动。你加 10 台机器，吞吐量只涨了 20%，那肯定有瓶颈。
• 错误率飙升：大量 502、504、连接超时、线程池拒绝。系统开始“丢请求”了。
• 资源利用率异常：CPU 跑满但 IO 空闲，或者 CPU 很低但线程全在 BLOCKED 状态。
• 日志出现大量“排队等待”：比如数据库连接池等待、线程池队列堆积、锁等待超时。

1.3 为什么抓包能定位并发瓶颈

很多人觉得抓包就是看看 HTTP 请求和响应，跟并发瓶颈有什么关系？

其实，抓包是定位并发瓶颈的“第一现场”。它能看到请求在网络上“卡”在哪里了。我举个例子：

假设一个下单接口，客户端发请求到服务端，服务端要查数据库、调库存服务、发消息队列。如果并发高了，到底卡在哪一步？

抓包能告诉你：

• 请求到达服务端的时间：客户端发出请求，服务端多久收到？如果网络延迟正常，说明问题不在网络。
• 服务端处理耗时：从服务端收到请求到发出响应，中间隔了多久？这个时间就是服务端处理时间。
• 服务端与下游的交互：服务端什么时候去查数据库？查询花了多久？调库存服务花了多久？这些都能从抓包中看到。
• 连接复用情况：是不是每次请求都新建连接？连接池有没有被耗尽？
• 重传和丢包：网络层面有没有丢包？TCP 重传多不多？这往往是并发高时网络栈扛不住的信号。

说白了，并发瓶颈的本质是“资源争抢”。而抓包能让你看到每个请求在争抢什么资源、等了多久、最终有没有抢到。这是其他监控工具很难做到的。

1.4 抓包定位并发瓶颈的核心逻辑

我画了一张图，帮你理解抓包定位并发瓶颈的整体思路：

从这张图你能看到，抓包分析主要从三个维度切入：

1. 请求耗时：看请求从发出到响应，每个环节花了多少时间。哪个环节耗时异常，瓶颈就在哪。
2. 连接状态：看连接是新建还是复用。如果大量新建连接，说明连接池可能不够用；如果连接等待时间长，说明资源争抢严重。
3. 网络质量：看有没有重传、丢包、窗口缩小。这些往往是并发高时网络栈扛不住的信号。

1.5 抓包 vs 其他监控手段

你可能想问：我有 APM、有监控大盘，为什么还要抓包？

我做个对比你就明白了：

看到了吧？抓包能看到其他工具看不到的“网络层细节”。而这些细节，往往是并发瓶颈的根源。

我记得有一次，监控显示一个接口 P99 延迟从 200ms 涨到了 2s。APM 说服务端处理时间正常，监控大盘说 CPU 和内存都没问题。最后抓包一看，发现客户端到服务端的网络延迟从 10ms 涨到了 800ms。原来是云厂商的负载均衡器在高并发下性能劣化。这种问题，不抓包根本发现不了。

1.6 本章小结

并发瓶颈的本质是资源争抢。它的表现有响应时间陡增、吞吐量上不去、错误率飙升等。抓包能定位并发瓶颈，是因为它能让你看到请求的“全链路时间线”，从网络层到应用层，每个环节的耗时和状态都暴露无遗。

接下来的章节，我会带你一步步掌握抓包工具的使用、抓包数据的分析方法，以及如何从抓包数据中精准定位并发瓶颈。咱们一步步来。