18|案例:如何排查RocketMQ消息发送超时故障?
现象与关键日志
单一长连接如何实现多请求并发发送?
- 深入了解
- 翻译
- 解释
- 总结
RocketMQ消息发送超时故障是一个常见且头疼的问题,本文通过排查案例详细介绍了排查RocketMQ消息发送超时故障的方法。首先,从客户端日志入手,分析关键日志,发现单一长连接实现多请求并发发送的原理。然后,通过诊断Broker端内存写入性能,排查网络层问题,最终发现网络读存在瓶颈。作者尝试了改造代码监控服务端的写性能,但最终通过调优RocketMQ的网络通信层参数解决了问题。作者将serverSelectorThreads和serverWorkerThreads参数分别调整为16和32,经过验证,生产环境的消息发送超时比例大大降低。文章总结了排查消息发送超时问题的全过程,并介绍了如何应对消息发送超时的方法。 文章还介绍了解决消息发送超时问题的另一个思路:增加快速失败的最大等待时长,并减少消息发送的超时时间,增加重试次数。具体做法包括增加Broker端快速失败的等待时长和减少超时时间、增加重试次数。此外,还介绍了调整RocketMQ的网络通信层参数以及如何包装RocketMQ API来降低网络超时对运行时线程的影响,降低系统响应时间。 总的来说,本文通过具体案例和技术细节,帮助读者了解了排查RocketMQ消息发送超时故障的方法,并提供了解决方案,对于从事消息中间件开发和运维的技术人员具有一定的参考价值。
《中间件核心技术与实战》,新⼈⾸单¥59
全部留言(3)
- 最新
- 精选
- koutann运维同事分别在客户端和 MQ 服务器上,在服务器上写一个脚本,每 500ms 采集一次 netstat 。从客户端的日志信息发现Recv-Q 中出现大量积压 ====== 这里MQ服务端采集到的netstat日志Send-Q有积压现象吗? 如果没有积压的话,因为服务器IO线程数量不足导致的问题,为啥会导致客户端的Recv-Q出现积压呢
作者回复: 这个问题问的非常棒,讲真,其实这里的逻辑,受限于我网络方面的知识,目前还不能给出一个底层的逻辑,后续解决这个问题,还是想着从网络层面再想想版本,就仔细阅读了相关的源码,发现的那两个参数,调整后确实效果好了,问题得以解决,关于网络方面,我估计在今年4季度会针对性的学习,学习成功将发布在我的公众「中间件兴趣圈」,欢迎关注,我们后续多多交流。
2022-09-07归属地:上海33 - 越过山丘return producer.send(msg,500); //设置超时时间,为 500ms,内部有重试机制 这里的500ms低于 Broker maxWaitTimeMillsInQueue=1000 会不会导致 Broker繁忙时候或者网络抖动时间,响应时间超过了500ms,导致客户端所有消息都重试多次,重试消息和之前的消息都积压在Broker的内存中,一方面对Broker造成压力,影响Broker的正常处理能力,一方面造成消息的重复率变高 目的是让客户端快速
作者回复: 对的,为你👍,消息发送阶段的重复率会变高,这里需要做权衡,主要是因为消息发送超时,会占用线程资源,如果并发比较高,消息发送超时发生概率大,就有阻塞线程,导致线程容易耗尽,造成用户使用响应极慢。当然在实践过程中,可以让设置的超时时间大于maxWaitTimeMillsInQueue
2022-09-11归属地:上海 - 小杰请教老师: 1、netstat里面的队列是tcp的发送和接受队列吗? 2、netty的发送缓存和tcp的发送缓存怎么个区别呢?怎么看这两个呢? 3、老师给的那个awk -F '[, ,:]' '$12>2' r.log |wc -l 为啥是12列,咋看不懂呢?2022-08-04归属地:北京