一、引言
适用人群:使用RocketMQ的程序猿。
文章目的:记录并收集RocketMQ在各种环境下出现的问题和解决办法。
二、简介
RocketMQ是一个纯java、分布式、队列模型的开源消息中间件,前身是Metaq,当Metaq 3.0发布时,产品名称改为RocketMQ.
具有如下特点:
- 能够保证严格的消息顺序
- 提供丰富的消息拉取模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
三、Q&A
1.背景:关于RocketMQ是否和业务强耦合,此处是指将业务混合在消息发送接收确认逻辑中。关于这种思想提供一个说明。
个人看法:RocketMQ作用只是提供消息传送功能,将消息传到目标服务器即完成工作,业务逻辑尽量不要混合在RocketMQ消费逻辑中,如有需要确认消息是否正确消费,需要业务系统编写逻辑监控。如果必须将消息是否消费逻辑耦合到RocketMQ,请保证代码正确,避发生消息堆积。
2.背景:关于AMC使用MQ出现消息堆积的情况,实际上是本地消费线程被挂起,这种情况会导致消费者线程池线程数量减少,直至消耗殆尽。
原因:AMC在使用RocketMQ对服务器操作进行分离时,在amc-consumer处理消息的方法中,存在使线程挂起的地方,导致在Broker接收成功,一直未返回消费结果。
解决办法:解决线程挂起,保证处理消息的方法无论是否处理成功过,都返回消费结果。
3.背景:集成项目使用mq时,出现连接Broker失败的情况,出现非Broker IP的“172.17.0.1”等个别IP。
原因:在Broker服务器发现存在多网卡配置,服务器上的Docker网卡影响到了MQ对本地服务器IP的正切取值。
解决办法:1.消除多网卡将不用的网卡禁用(不推荐,可能影响到别的软件运行)。
2.通过Broker参数BrokerIP1指定本地Broker连接到NameServer服务器的IP。
4.背景:相关业务系统在使用mq时,出现消息未消费情况。
原因:集成环境消费端业务逻辑处理异常,消息已经接受但并未成功消费。
解决办法:将业务方法优化,增加失败监控机制,确保方法完全执行。
5.背景:使用RocketMQ时,同一个消费组由于订阅关系不一致(在一个Topic下,同一个消费组,两个消费者订阅了不同的tag),导致消息无法正常消费。
原因:由于订阅关系不一致在MQ负载均衡时,发生消费错误、无法消费到消息的问题。
解决办法:对于同一个消费组,应保持各个消费者之间的订阅关系一致。