rocketmq

1 原理

主要分为4个部分：producer，nameServer，broker，consumer 

nameServer:作用类似于zookeeper，broker的注册中心，consumer需要到nameServer上找到对应的broker，消费消息。

broker:每一个broker会存储多个topic，一个topic有多个读写队列，集群模式下，一个topic的一个队列，只会被一个消费者消费（一个消费者可以消费多个队列）。

1.5 防止消息丢失

由于最近面试，有面试官问我如何防止消息丢失，下面介绍一下本项目防止消息丢失的手段。

    1.5.1发送端防止消息丢失  

     首先消息丢失可以发生在很多阶段，1producer 往Broker中发送消息

     发送消息的类使用 DefaultMQProducer的send 方法

     如下：

只需要根据这个send的返回值，来判断消息是否发送成功，发送成功，消息就到了broker上。

 在发送消息的message 类中，放入这些参数，便于后序判断消息的来源

 

1.5.2 broker上防止消息丢失

此处参考网上其他说法，将broker消息保存机制改为同步刷盘方式

flushDiskType = SYNC_FLUSH

原先的默认值为ASYNC_FLUSH

具体原理：消息发送到broker上之后，被保存到内存中同事broker就返回参数给producer，在这之后，broker将消息从内存刷入磁盘。也就是说，可能返回了成功，但是刷入磁盘是失败的。

此外本项目，一个topic的消息会被放入多个broker中（下面图有是4个broker），这些broker都是master。

1.5.3 consumer端的消费失败

简单描述一下，如果消费失败比如执行异常，那么会返回

return ConsumerResult.RECONSUME_LATER;

得到这个失败的情况后，消息会每隔更长的时间继续被消费，超过了一定范围，比如7天，再也不会被消费。

消费成功返回CONSUMER_SUCCESS，不会再推或者拉这个消息过来消费。

return ConsumerResult.CONSUMER_SUCCESS;

2 配置

3 rocketMq 控制台

4个集群，均为master，用来读写

读写队列均为4

本项目的订阅组为dat_gh_ebiz_esp_consumer,配置如下图

图中是一个组消费多个topic，当然也可以是一个topic被多个组消费

被动消费  即使用pull方式消费消息