Rocketmq如何保证消息不丢失

一、前言

RocketMQ可以理解成一个特殊的存储系统,这个存储系统特殊之处数据是一般只会被使用一次,这种情况下,如何保证这个被消费一次的消息不丢失是非常重要的。本文将分析RocketMQ从哪些方面来保证消息的不丢失。

二、消息什么情况会丢失?

由于消息从生产者,到broker,最后被消费者消费,中间最少经历了3个应用2次rpc调用,由于rpc调用会存在成功失败外的第三种情况,因此消息会存在不可靠性。

那么,我们有哪些手段来提升消息的可靠性呢?本文将分别从生产者端,消费者端,broker端来分析保证消息不丢失的手段。

三、如何保障消息不丢失?

1、生产者端

生产者发送消息,有同步发送异步发送到Broker。

我们如果对消息可靠性要求比较高,我们可以选择同步发送。在RocketMQ的客户端,同步发送自带重试机制,如果同步模式发送失败,则轮转到下一个Broker。

如果重试都发送失败了怎么办呢?

这时候我们要考虑发送失败的兜底方案-业务系统自己实现,业务系统可以将消息存储起来,使用定时任务等机制来重发消息。

2、Broker端

作为Broker,他的主要职责就是将消息持久化存储起来,同时最少把消息投递到消费者端一次

由于消息是存在磁盘上的,因此持久化机制就会涉及到刷盘机制。RocketMQ支持同步刷盘和异步刷盘机制。

RocketMQ处理发送消息请求时默认写入缓冲区,不会立即同步落盘,通过定时5s进行刷新落盘

SYNC_FLUSH,同步刷盘,刷盘完成再返回给客户端,超时5s

ASYNC_FLUSH,异步刷盘,200ms刷新一次,性能高

上面的机制可以保证存储可靠性,Broker除了保证存储消息可靠外,broker还需要保证消息能够投递给消费者消费一次。Broker如何保证消息一定会投递给消费者呢?

Broker端设计了重试机制。如果消息消费失败了,会将消息写到重试topic下的队列,会最大重试16次发送到消费者端。

如果16次之后,消息还是没有消费成功,Broker端会将消息写入死信队列

3、消费者端

消息投递到了消费者端,消费者如果消费不成功,不能给broker端返回ack。一般需要设置为手动提交ack机制,消费者消费消息不成功,不返回CONSUME_SUCCESS,返回RECONSUME_LATER表示需要broker再次投递该消息。

这里需要注意的是,由于broker保证消息不丢失有重试机制,可能导致消息重复投递,因此消费者端需要做幂等性处理,一般会根据业务规则处理。

四、总结

消息系统将不同的系统进行解耦,在提高了系统的高吞吐量和异步性能的同时,也对系统稳定性带来了挑战,消息保证可靠性不丢失就是非常关键的一个稳定性挑战,本文分别从生产者,Broker,消费者端三端来考虑对应方案来处理消息不丢失的手段。

相关推荐
阿镇吃橙子1 分钟前
一些手写及业务场景处理问题汇总
前端·算法·面试
逆袭的小黄鸭2 分钟前
JavaScript:作用域与作用域链的底层逻辑
前端·javascript·面试
Smilejudy7 分钟前
不可或缺的相邻引用
后端
惜鸟7 分钟前
Elasticsearch 的字段类型总结
后端
rebel9 分钟前
Java获取excel附件并解析解决方案
java·后端
微客鸟窝11 分钟前
Redis常用数据类型和命令
后端
熊猫片沃子13 分钟前
centos挂载数据盘
后端·centos
微客鸟窝14 分钟前
Redis配置文件解读
后端
不靠谱程序员15 分钟前
"白描APP" OCR 软件 API 逆向抓取
后端·爬虫
小华同学ai17 分钟前
6.4K star!企业级流程引擎黑马,低代码开发竟能如此高效!
后端·github