一、简介

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.背景：相关业务系统（auto）在使用mq时，出现消息未消费情况。

原因：集成环境消费端业务逻辑处理异常，消息已经接受但并未成功消费。

解决办法：将业务方法优化，增加失败监控机制，确保方法完全执行。

5.背景：使用RocketMQ时，同一个消费组由于订阅关系不一致（在一个Topic下，同一个消费组，两个消费者订阅了不同的tag），导致消息无法正常消费。

原因：由于订阅关系不一致在MQ负载均衡时，发生消费错误、无法消费到消息的问题。

解决办法：对于同一个消费组，应保持各个消费者之间的订阅关系一致。

备注：创建时间：2017-03-03 17:02:17   个人博客转移文档