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

    

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值