本次问题涉及的系统链路如上图，各系统的基本职责为：

说明：本文用到的消息队列内部称 MetaQ，外部开源版即为 RocketMQ，下文中统一用 “MQ” 指代。

某天上午收到报警通知，提示 Proxy 系统的入口 MQ 有堆积。打开控制台，发现 500 台 Proxy 机器中，有 1 台机器堆积十分严重，而其余机器均运行正常：

先开门见山直接讲问题根因（详细排查流程可参考后文内容）：

1）该机器消费速度太慢？

第一反应是这台机器的消费太慢。同样的消息量，别的机器能快速消化，而它由于消费慢于是持续堆积。然而在 MQ 控制台详细对比后，发现该机器的业务处理时长、消费 TPS 都与其他机器相近，且不同机器的规格本身也是一样的：

其次，观察 Arthas 画出的火焰图，右边两根比较细长的火焰即为我们系统的业务逻辑（火焰比较高是因为 RPC 的调用栈比较深）。从图中可看出，火焰图并没有明显的“平顶效应”，火焰的宽度都比较窄，也可说明该机器在执行业务逻辑时中并没有明显的耗时卡点，由此也可证明该机器并不是因为业务处理慢而造成的堆积：

2）系统指标是否正常？

登录机器，发现 CPU、MEM、LOAD 均正常，且与正常机器相近，没有发现明显线索：

且该机器并无明显的 Full GC：

3）限流导致？

因此，假如今天系统流量很大，超出了下游服务能承受的限制，则超出部分的请求会触发 RateLimiter 限流而阻塞。于是大量 MQ 消费者线程被阻塞，故 Proxy 系统整体的消息消费速度会变慢，最终体现的结果即为入口 topic 堆积。

然而，不管是看该机器的日志还是监控，因限流而阻塞的现象都并不严重，比较通畅：

其次，如果真是因为今天系统入口流量大导致，那应该所有 Proxy 机器（MQ 消费者）都会出现程度相近的堆积。不应该全堆在同 1 台机器上，而其他 499 台机器都正常。因此，排查系统入口流量太大的可能性。

4）MQ 数据倾斜？

预期应该是 500 台 Proxy 机器均分入口 MQ 里面的消息，有没有可能是数据分配时出现了倾斜，导致这台机器分到的消息量太多，其他机器分到的消息很少？

查看 Proxy 上游系统的代码，该系统在向 Proxy 发消息时并没有做自定义 Shuffle，于是会使用 MQ 默认的selectOneMessageQueue策略。而该策略会把当前消息发到基于index % queue_size选出的队列中。进一步查看 index 的逻辑，发现它初始化时以一个随机数为起点，每次访问时会 +1 自增：

结合以上两点，实现的效果即为：对各个 queue 从左到右、均匀地分发消息，并通过 % 实现自动循环：

综上可知，MQ 默认 shuffle 策略为：把消息均分到各个 queue 中。因此，可排除因为 MQ 发送消息数据倾斜，导致我们那台 Proxy 机器堆积的可能性。

5）CPU steal ？

比如机器规格本身写的是 4C，实际因为被 steal 后能用的可能只有 2C。所以体现的结果就是单个请求的 RT 无明显变化（不同 C 之间差异不大），但 C 的量变少了，所以这台机器整体吞吐变小、消费能力变弱，导致堆积。

但排查发现，st 正常，排除这种可能：

6）找到线索：MQ 消费位点没变！

兜兜转转一圈都没找到异常点，由于问题现象是 MQ 堆积，所以又想到可以去查看中间件的日志寻找线索。果然，通过定向搜索卡住机器的 queueId，发现这个队列的消费位点长时间不推进，一直卡在某个位置：

由此怀疑：是否因为 Proxy 消费停止 or 消费极慢，导致本地缓存一直是满的，于是 MQ 会停止向 queue 中拉消息，于是 offset 一直没变？

但上文已提到，不管从 MQ 控制台、系统监控指标、机器日志来看，该机器都是正常的，与其余机器没什么区别。那为什么该机器的消费位点就是不动，导致堆积越来越严重？

7）找到根因：某个消费者线程卡住了

首先，这个机制是合理的。因为在 At Least Once 语义下，消息允许被消费多次但不允许被遗漏。假设现在有两个线程同时拉取了前后两条消息，且后面的消息先执行完毕。由于前一条消息的执行可能会出现异常，所以不能直接用后者的偏移量去更新 offset，否则消费失败的消息就找不回了。因此，消费位点 offset 的含义是：在该位置及之前的所有消息都已经被正确消费（有点类似 Flink 的 Watermark 机制）。

根据以上机制，回到本问题，假如这台 Proxy 机器的众多 MQ 消费者线程中有任意一个被卡住，那么整个 queue 的消费位点将永远停留在被卡住的消息对应的 offset。此时虽然其他线程都在持续正常消费，但并不能往前推进 offset。另一方面，由于上游还在源源不断往队列中发消息，于是消息只进不出，堆积量 = 最新入口消息的offset - 消费位点offset只增不减，体现在控制台上就是堆积越来越严重！

基于此分析，通过 jstack 查看所有 MQ 消费者线程的状态，的确发现第 251 号线程永远处于 runnable 状态！

有理由怀疑，它就是被卡住的消费线程。因为在 Proxy 系统的业务场景中，绝大部分耗时都在 RPC 同步调用深度学习模型这个环节（快的几百毫秒，慢的可能要几秒），因此线程大部分时间应该处于等待同步调用返回的 waiting 状态！而此处 251 线程永远是 runnable，一定有问题。

进一步打印详情，可找到线程卡住的具体代码位置：

这里getImageDetail方法内部会通过 HTTP 下载图片，以便深度学习模型进行预估。其次，搜索业务日志也发现，搜不到这个线程的日志。因为从昨晚 10 点开始卡住后，该线程就不会产生任何新的日志了，随着机器日志滚动清理，现在所有日志都将不含该线程的内容：

至此，Proxy 系统个别机器 MQ 堆积严重的问题根因找到：该机器的某个消费者线程在通过 HTTP 下载图片时一直卡住，导致整个 queue 的消费位点无法往前推进，从而持续堆积。

8）为什么 HTTP 会一直卡住？

至此，虽然堆积的根因已经找到，且经过尝试短期内可通过应用重启/机器下线等方式临时解决。但长远来看始终存在隐患，因为近期每隔几天时不时就会出现相同问题。需要彻底查清楚 HTTP 卡住的根因，才能从根本上解决本次问题。

通过几次蹲点，捞到了一些会导致线程卡住的图片 URL。发现它们都不是内部的图片地址，且地址也打不开，也不是 jpg 形式结尾的格式：

https://ju1.vmhealthy.cnhttps://978.vmhealthy.cnhttps://xiong.bhjgkjhhb.shop

但问题是，即便是输入这种打不开的极端 URL，由于我们对 HttpClient 设置了 5s 超时，顶多也就会卡住 5s 啊，为什么好像超时机制没生效，一直卡住了十多个小时？

经检查，目前代码中只设置了 socket timeout，没设置 connection timeout，因此怀疑上面那些请求直接卡在了前面的 connect 阶段，而又由于没设置 connect 超时，所以请求一直卡住？然而，修改代码后重新尝试请求这些地址，发现还是会一直卡住，需要进一步排查。

9）找到 HTTP 卡住的根因

再回过头看上面那几个卡住的 URL，无一例外都是https开头的！破案了，原来是项目用的 HttpClient 有 bug。在升级了 HttpClient 版本后，重新在预发构造测试请求，线程不再卡住，且全部发到线上环境后，近期频繁出现的少量机器堆积问题再也没有出现过。

至此，经历了许多曲折，问题终于彻底解决。

从最外层 Proxy 个别机器堆积的表象，不断往内层排查中经历了许多关键节点，直到找到根源。目前所有问题已全部查清，现在站在上帝视角，从内向外完整的因果链条如下：

--> Proxy 系统会基于 HttpClient 去下载图片，然后调用图像类模型做预估；

--> 所使用 HttpClient 版本有 bug，在访问 https 地址时，超时不会生效；

--> Proxy 系统恰好遇到了少量 https 地址，且恰好卡住（低概率事件），于是会因超时不生效而一直卡住；

--> 基于 MQ 的 At Least Once 机制，消费位点将一直停留在卡住消息所对应的 offset 处（尽管其余线程都在正常消费）；

--> 上游系统仍然源源不断向 Proxy 发送消息，于是消息只进不出，堆积越来越严重；

--> 堆积量超过一定阈值，触发监控报警，用户察觉。

本次问题的排查过程略微曲折，但也能学到不少共性的方法论和经验教训，在本节统一提炼归纳：