中间件核心技术与实战
丁威
中通快递资深架构师,RocketMQ 社区首席布道师
19674 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 33 讲
中间件核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

18|案例:如何排查RocketMQ消息发送超时故障?

你好,我是丁威。
不知道你在使用 RocketMQ 的时候有没有遇到过让人有些头疼的问题。我在用 RocketMQ 时遇到的最常见,也最让我头疼的问题就是消息发送超时。而且这种超时不是大面积的,而是偶尔会发生,占比在万分之一到万分之五之间。

现象与关键日志

消息发送超时的情况下,客户端的日志通常是下面这样:
我们这节课就从这些日志入手,看看怎样排查 RocketMQ 的消息发送超时故障。
首先,我们要查看 RocketMQ 相关的日志,在应用服务器上,RocketMQ 的日志默认路径为 ${USER_HOME}/logs/rocketmqlogs/ rocketmq_client.log。
在上面这张图中,有两条非常关键的日志。
invokeSync:wait response timeout exception.
它表示等待响应结果超时。
recive response, but not matched any request.
这条日志非常关键,它表示,尽管客户端在获取服务端返回结果时超时了,但客户端最终还是能收到服务端的响应结果,只是此时客户端已经在等待足够时间之后放弃处理了。

单一长连接如何实现多请求并发发送?

为什么第二条日志超时后还能收到服务端的响应结果,又为什么匹配不到对应的请求了呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

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归属地:上海
    3
    3
  • 越过山丘
    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归属地:北京
收起评论
显示
设置
留言
3
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部