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方式消费消息