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,消费者端三端来考虑对应方案来处理消息不丢失的手段。

相关推荐
雷渊17 分钟前
微服务中为什么要设计不同的服务和不同的数据对象,体现了一个什么样的设计思想?
后端
掘金安东尼17 分钟前
前端周刊第421期(2025年7月1日–7月6日)
前端·面试·github
无奈何杨1 小时前
CoolGuard风控中新增移动距离和移动速度指标
前端·后端
程序员爱钓鱼1 小时前
Go语言泛型-泛型约束与实践
前端·后端·go
寻月隐君1 小时前
保姆级教程:Zsh + Oh My Zsh 终极配置,让你的 Ubuntu 终端效率倍增
linux·后端·命令行
前端小巷子1 小时前
web从输入网址到页面加载完成
前端·面试·浏览器
程序员爱钓鱼1 小时前
Go语言泛型-泛型对代码结构的优化
后端·google·go
这里有鱼汤1 小时前
“对象”?对象你个头!——Python世界观彻底崩塌的一天
后端·python
RainbowSea1 小时前
跨域问题(Allow CORS)解决(3 种方法)
java·spring boot·后端
sniper_fandc3 小时前
SpringBoot系列—入门
java·spring boot·后端