预计500 台代理机器将在入口MQ 处均匀分发消息。是否有可能数据分布存在倾斜，导致本机收到大量消息而其他机器收到很少消息？
检查代理上游系统中的代码。该系统在向代理发送消息时不执行自定义洗牌，因此使用MQ 默认值。
选择一个消息队列
战略。该策略使用当前消息
索引% 队列大小
选定的提示。如果我们更仔细地观察索引逻辑，我们可以看到它在初始化时以随机数开始，每次访问时都会增加+1。
结合以上两点将确保消息从左到右均匀分布在每个队列中，从而产生带有% 的自动循环。
综上所述，我们可以看到MQ默认的shuffle策略是将消息均匀的分发到各个队列中。这样就消除了MQ发送的消息数据出现倾斜并堆积在代理机上的可能性。
5. 偷CPU？
提示：CPU 窃取表示虚拟机内运行的进程被主机上的其他进程/虚拟机占用的CPU 时间百分比。高CPU 窃取值通常意味着虚拟机的进程性能不佳。
例如，机器的规格本身说是4C，但实际上被盗后可能只有2C。因此，反映的结果是单个请求的RT变化不大（不同C之间的差异威力会减弱。导致积累。
但经调查，发现st正常，排除了这种可能。
6.我们发现了一个线索：MQ的消费地点没有改变！
我环顾四周，却没有发现什么异常。由于问题是由MQ堆积引起的，所以我决定检查中间件日志。果然，定向查找卡住的机器的queueId，发现这个队列的消费点已经很久没有推进了，卡在了某个位置。
提示：MQ 拉取消息机制首先将拉取的消息存储在内存中容量为1000 的缓存中，然后由消费者线程消费内存中的这些消息。一旦缓存已满，就不再从队列中检索数据。
从这里开始，我想知道。也许代理已经停止消费或者太慢以至于本地缓存总是满的并且MQ停止将消息拉入队列，因此偏移量没有改变？
但是，如上所述，从MQ 控制台、系统监控指标和机器日志中看到，该机器是健康的，与任何其他机器没有什么不同。那么为什么机器的消耗点保持不变，并且积累越来越严重呢？
7.查找根本原因：消费者线程卡住
提示：对于本地缓存中的消息，MQ 会开启多个线程（线程数由用户指定）来检索消息。另外，为了避免丢失消息，偏移量只记录第一条消息。
首先，这个制度是合理的。这是因为At Least Once 语义允许消息被多次使用，但不会被错过。假设有两个线程同时拉取两条消息，后一条消息先执行。后者的offset不能直接用来更新offset，因为前一条消息的执行可能会出现异常。否则，无法被消费的消息将不会被检索。所以消费位置偏移的意义就是这个位置及之前的所有消息都被成功消费（有点类似于Flink的水印机制）。
基于上面的机制，回到这个问题，如果这台代理机上的众多MQ消费者线程中的任何一个线程发生卡住，那么整个队列的消费位置将始终停留在卡住消息对应的偏移量处。目前，其他线程继续正常消费，但无法向前推进偏移量。另一方面，上游不断向队列发送消息，因此消息只能输入，不能输出。
累计金额=最新入场消息偏移量-消费仓位偏移量
只增不减，这一点体现在主机上的积累越来越严重。
基于这样的分析，当我通过jstack查看所有MQ消费者线程的状态时，居然发现251号线程始终处于可运行状态。
有理由怀疑消费者线程被卡住了。在代理系统的业务场景中，大部分时间都花在了对深度学习模型进行RPC同步调用上（快则数百毫秒，慢则秒），因此线程大部分时间都必须花在等待上。在。同步调用现在返回等待状态。在任何给定时间有251 个线程可供运行。一定有什么问题。
打印更多详细信息可以让您找到线程卡住的具体代码位置。
这里
获取图像详细信息
在该方法内部，图像通过HTTP 下载，以便深度学习模型可以进行预测。然后我搜索了业务日志，发现没有找到该线程的日志。该线程自昨晚10:00停止以来尚未生成任何新日志，因此滚动机日志清理将确保所有日志不再包含该线程的内容。
至此，我们已经确定了代理系统内各个机器上出现严重MQ 累积问题的根本原因。通过HTTP 下载图像时，机器的消费者线程被卡住，导致整个消费点队列无法继续前进。从而不断积累。
8. 为什么HTTP总是卡住？
至此，您已经找到了堆积的根本原因，但经过一些实验后，您可以通过重新启动应用程序或使机器离线来在短期内暂时解决它。但从长远来看总是存在隐患的，因为最近每隔几天就会出现同样的问题。要从根本上解决此问题，您需要彻底调查HTTP 堆栈的根本原因。
蹲了几次，发现一些图片网址导致线程卡住。原来这些都不是内部图片地址，无法打开，也不是jpg结尾的格式。
https://ju1.vmhealthy.cnhttps://978.vmhealthy.cnhttps://xiong.bhjgkjhhb.shop 但是问题是，即使输入打不开的极端URL，最多也会停止5秒，因为HttpClient设置了5秒超时。为什么超时机制没有生效，并且出现卡住10多个小时的情况？
提示：使用HTTP 时，必须先建立连接，然后才能发送数据。这对应于两种类型的超时： 1、连接建立阶段连接超时。 2. 数据传输超时。
经检查，当前代码只有socket超时，没有连接超时，因此我们认为上述请求直接卡在了上一个连接阶段。另外，请求是否总是被卡住，因为没有设置连接超时？但是，即使在更改代码并尝试再次请求这些地址后，它们仍然被卡住，因此我需要进一步调查。
9. 找到HTTP 堆栈的根本原因
提示：找到根本原因。某些版本的HttpClient 在基于SSL 连接的请求中存在错误。它实际上首先尝试建立连接，然后设置超时，顺序相反。因此，如果连接卡住并且没有配置超时，HTTP 请求将继续卡住。
回顾一下上面卡住的网址，无一例外都是：
https
开始！原来项目中使用的HttpClient有bug。升级HttpClient版本后，测试请求已预组装，线程不再卡顿，一切都发送到线上环境。最近经常出现的积少机问题不再出现。
经过一番周折，这个问题终于得到彻底解决。
2.4 总体回顾
从Proxy最外层的单机集群开始，我们继续排查，追踪内层的许多关键节点，直到找到根本原因。现在所有的问题都清楚了，从神的角度来看，从内到外完整的因果关系是这样的：
— 代理系统基于HttpClient下载图像并调用图像类模型进行预测。
— 使用的HttpClient版本存在bug，导致访问https地址时不超时。
— 代理系统碰巧遇到少量https地址而卡住（低概率事件），由于没有超时生效而一直卡住。
— 基于MQ的At Least Once机制，消费点始终保持在堆栈消息对应的偏移量处（尽管其他线程正在成功消费它）。
— 上游系统还在不断地向代理发送消息，所以消息只能接收不能发送，并且堆积越来越严重。
— 如果累计超过一定阈值，就会触发监控报警，用户就会意识到
三、总结
解决这个问题的过程有点复杂，但我们也学到了很多常用的方法和教训。本节对这些内容进行了总结。
充分利用我们的故障排除工具。
学习如何使用jstack、Arthas、jprofile等优秀工具，并在不同情况下有效地利用正确的工具，有效地发现异常，找到线索，从而逐步找到问题的根源。
异常敏感：
现实中，发现问题的蛛丝马迹可能会在早期就显露出来，但由于各种原因（例如问题本身存在很多疑点、存在很多干扰因素没有排除等），可能会导致问题的出现。找不到。你需要快速积累更多的经验。
查看广泛的信息：
除了在内网上查阅文件、咨询利益相关者之外，还应该学会直接在外部英文网站上查阅信息。
即使在困难时期也要坚持：
有些隐藏的问题出现后可能不容易发现和解决。可能需要多轮故障排除才能最终找到根本原因。
补充基础知识。
如果一开始就知道MQ偏移是如何工作的，那么有些问题就会少走弯路。使用不同中间件的后续流程需要更多地了解其基本原理。
没有形而上学的问题：
每一个“形而上”问题的背后都是代码和机器无法欺骗人类。
参考：HttpClient 错误：https://issues.apache.org/jira/browse/HTTPCLIENT-1478
连接超时和套接字超时：https://stackoverflow.com/questions/7360520/connectiontimeout-versus-sockettimeout
本文和图片来自网络，不代表火豚游戏立场，如若侵权请联系我们删除：https://www.huotun.com/game/623132.html