一、引言
适用人群：使用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负载均衡时，发生消费错误、无法消费到消息的问题。
解决办法：对于同一个消费组，应保持各个消费者之间的订阅关系一致。
