RocketMQ学习总结

1、吞吐量：kafka>rocketmq>rabbitmq；消息堆积：kafka>rocketmq>rabbitmq；

2、rocketmq天然支持集群配置，默认conf配置下有两主两从异步、两主两从同步、两主没有从

3、为了保证正确运行，最好给出4g内存

4、先启动namesrv再启动broker，rocketmq控制台官方没有给，但是有开源爱好者研发rocketmq控制台的图形化管理界面，可以下载下来用idea运行即可查看，或者打成包运行也行。地址：https://github.com/apache/rocketmq-externals

5、Name Server相当于一个注册中心，记录生产者、消费者、broker集群的信息。所以要先启动Name Server

6、Producer发送消息，会默认发送到4个队列中并存储，队列是有序的。

7、针对事务消息的应答状态（LocalTransactionState）：COMMIT_MESSAGE、ROLLBACK_MESSAGE、UNKNOW(未知状态，一般用于处理超时等现象)；针对消费方消费的应答状态（ConsumerConcurrentlyState）：CONSUME_SUCCESS(消费成功)、RECONSUME_LATER(消息重试，消费失败以后重试机制)。（4.4以后变了，看完以后自己查查）SUSPEND_CURRENT_QUEUE_A_MOMENT

8、事务消息可以解决分布式事务以实现数据最终一致性，同时通过补偿机制对消费者消费出问题进行补偿。

9、RocketMQ有推拉两种方式，拉取消息是消费者直接从broker拉取，推送并不是broker直接将消息推送给消费者，而是消费者向broker发送请求，然后broker定时扫描其收到的消息，如果发现是消费者需要的，则会主动推送给消费者。

10、顺序消息

顺序消息需要三个阶段去保证：消息按照顺序发送；消息被存储时保证和发送的顺序一致；消息被消费时保证和存储的顺序一致。

RocketMQ能严格保证顺序消息，但这不是全局顺序，只是分区顺序（queue）。

只用一个队列的话可以保证全局顺序。或者同样的消息只发送到某一个队列。

顺序消息有低延迟性，因为要扫描所有的队列。

11、批量发送消息

RocketMQ默认消费模式是集群模式，若要批量消费，则设置成广播模式。

12、消息的存储和发送

消息的存储采用顺序写磁盘，效率比随机写磁盘快6000倍，消息从磁盘读出来发送给消费者，采用的零拷贝技术，不然发送要经过四次复制，效率比较低。零拷贝技术默认单个文件1.5-2G，rocketmq默认单个commitLog是1G。

13、

commitLog存储在rocketmq/store下，其存储的是消息的元数据，大小默认为1G。

为了提高CommitLog的查询效率，因此有了ConsumerQueue，其存储了消费消息的偏移量，可通过偏移量快速在commitLog中查找到消息。

14、如何保证高可用性？

nameServer：nameServer是无状态的，如果新加一个nameServer无需重启整个集群，直接添加就行，等nameServer集群发现该新节点，就会主动将broker集群的信息同步一份信息新节点。

broker集群：依靠主从来保证高可用性。master负责读写，而slave只负责写，不跟生产者交互只跟消费者交互。 

消费者的高可用性：消费者默认是跟master交互的，当master比较繁忙或者不可用时，消费者会自动从slave读取数据，这个不需要我们控制，broker会自动控制。

15、消息消费重试

消息消费失败可以设置重试，但是只适合集群消费，对于广播模式的消费，没有消息的重试，只有一次消费，无论成功失败都不会有消息的重试。RocketMQ默认最多重试16次。

16、死信

消息消费超过重试次数，消息变为死信，进入死信队列，死信队列是针对消费者组来的，一个消费者组对应一个死信队列，如果该消费者组没有产生死信，则没有死信队列。

死信队列中的消息无法再次被消费，死信队列中的数据跟正常消息一样三天之后就会被删除，因此三天之类必须要处理死信消息。

可通过控制面板再次发送死信消息，或者再单独写个消费者消费死信队列。

17、重复消费

可能产生重复消费的情况：

（1）生产者发送消息给broker，broker本地持久化还没反馈，结果生产者宕机或者网络波动，没收到反馈，生产者会再发一条给broker，broker持久化两条，会发给消费者两条；

（2）消费者消费以后还没反馈给broker，然后宕机或者网络波动，broker一段时间以后收不到反馈会重试，导致消费者二次消费；

（3）当消费者实例重启或者宕机，会触发负载均衡重排，已经消费的队列可能会被分配到新消费者，导致不同的消费者消费了相同的消息。

消息消费做幂等：

不能用messageID，RocketMQ不保证消息的messageID唯一，因此可能不同的消息有同一个messageID，因此不能用messageID。可以用业务的唯一标识，发送消息是传过去一个key，这样对这个key进行做幂等。消费者本地可将消费以后的key存入数据库，当每次收到消息以后与数据库对比，若key能查到，则不再消费。