rocketmq深入一

  这里先抛出一系列问题，然后对每个问题做深入。

  

1.为什么性能会比activemq，rabbitmq好

1.1.为什么数据记录记录在commitLog，然后存在索引会比直接记录消息实体无索引能够有更加好的性能

2.rocketmq有哪些好的点，可以学习

2.1.消息消费的方式采用消息者长连接拉取形式，能够保证一定的消息及时性

如果采用推送形式可能会将消费者压垮。

3.activemq，kafca，rabbitmq，分别适用于什么业务场景

4.如何保证消息消费顺序性

rocketmq通过单个producer发送消息到单个queue，来使消息消费顺序化。

如果让消息中间件实现严格的消费顺序性成本就比较大。意味着在消费者取消息时，有一个串形化结点来控制消息消费的顺序性。

5.如何保证消息消费优先级

可以采用不同优先级发送到不同topic来解决。

同样消息中间件如果要实现这种优先级，需要有个排序功能。而消息由于在rocketmq是序列化的因此成本会非常大。

6.如何保证消息过滤

消息过滤目的是减少无用消息传输到消息端。

通常两种方式：

a.broker端进行过滤，即消费者过来取消息时根据消息的tag设置来过滤。缺点是会增加broker处理负担。

b.消费端也需要根据自己设置的tag来过滤。

我比较倾向于a方案，broker成本不会特别大，只需比较消息的tag与消费者的tag即可。

7.消息可能到达消费者重复，怎么处理

原因是：broker发送消息给消费者可能出现网络异常，导致消息被重复

8.是否支持回溯消费消息

支持，在消费者消费完后，但后面业务结果已经丢失的情况需要用到。

9.rocketmq对于消息堆积怎么做

消息堆积指标：

发送者发送消息吞吐量，消息消费者消费消息吞吐量。

10.rocketmq是否支持分布式事务

首先明确分布式事务，主要指多件事情要么都做了，要么都没做，而这几件事情不能由数据库一个本地事务完成。因此需要分布式事务。

举个例子：下完单后需要发送下单成功消息给用户，这里会发生下单成功但进程挂了，消息未发送。解决方法有很多，分布式事务就是一种。

用rocketmq实现分布式事务就是，一阶段发送事件消息（状态为初始化）给broker，然后做下单操作。下单操作成功后发送二阶段修改事件消息状态给broker，broker会将事件消息状态置为［成功］，这时消费者能够消费到这条消息并能够向用户发送消息了，当然不重复给用户发消息就需要另外方案处理幂等了。

rocketmq开源版本目前不支持，是一个不完整的实现版本。有几个开源用户补充写了这部分功能。

11.rocketmq是否支持定时消息

支持，broker层做。支持5s,10s，1m等。