原创

分布式消息中间件(十)——RocketMQ的消息丢失

我曾经在分布式系列中讲解过消息丢失,当时主要从RabbitMQ和kafka是如何应对消息丢失的。本章,我们先来回顾下消息丢失的场景,然后看看RocketMQ是如何解决消息丢失的问题的。

一、消息丢失场景

《系统改造:异步、解耦、削峰》一章,我们通过引入RocketMQ使得系统之间解耦,如下图:



物流、积分、促销、通知系统通过订阅RocketMQ中的消息与订单系统进行交互。那么,这个过程中如果消息丢失了怎么办呢?消息丢失可能发生在以下几个场景。

1.1 生产者消息丢失

订单系统,发送支付成功的消息到MQ中,这个时候恰巧可能网络发生了抖动,也就是网络突然有点问题,导致这次网络通信失败了,消息就丢失了:



1.2 中间件消息丢失

当消息写入MQ之后,MQ可能仅仅是把这个消息给写入到PageCache中,然后就返回成功响应了,但此时消息还在OS缓存中,如果此时机器宕机了,消息就丢失了:



此外,就算数据刷到磁盘上去了,但如果你的磁盘出现故障,比如磁盘坏了,上面存储的数据还是会丢失。

1.3 消费者消息丢失

接着往下看,假设积分系统从RocketMQ拉取到了一个消息,偏移量是offset=10,正常情况下,积分系统处理完自身逻辑后会响应给RocketMQ,告诉它offset=10这个消息已经消息成功了。

但是,有的消息中间件,比如Kafka,会消费者一消费成功就会自动提交offset,此时如果消息的自身逻辑处理异常或宕机,就会导致MQ认为已经消费成功,但事实上消费失败了,从而出现了消息丢失的现象。



二、消息零丢失方案

了解了消息丢失的三类基本场景,我们就来看看,RocketMQ怎么才能保证全链路的消息零丢失。

2.1 生产者侧

我们先来看下生产者侧怎么保证消息不丢失,也就是生产者100%将消息投递成功

在RocketMQ中,提供了事务消息机制,凭借这个事务级的消息机制,就可以确保生产者能将消息投递成功。这里其实涉及到了分布式事务的概念,但是我们本章不会展开,有兴趣的童鞋可以参考我写的分布式系列

half消息

以我们的订单系统为例,假设它收到了一个订单支付成功的通知,它首先会发送一条half消息到RocketMQ中去。这个half消息,你可以理解为消息的状态是half状态,这个时候积分系统是看不见这个half消息的。



为什么要先发送一个half消息呢?

因为订单系统收到支付成功的通知后,如果直接操作本地数据库操作成功了,但是投递消息失败了(比如MQ挂了或网络有问题),会造成积分增加不成功,出现数据不一致的情况。所以,先投递一个half消息,初步跟MQ做个沟通,确保网络和MQ暂时都没问题。

接着,发送half消息成功并得到响应后,订单系统就开始执行自己的本地操作,比如更新订单状态等等:



如果本地事务执行失败了,订单系统就发送一个rollback请求给MQ,告诉它将刚才那个half消息给删除掉,不需要走后续流程了:



如果本地事务执行成功了,订单系统就发送一个commit请求给MQ,告诉它将刚才那个half消息进行commit操作,这时积分系统就可以看到并消费这个消息了:



回调接口

RocketMQ有一个针对Half消息的补偿机制,它会去扫描所有未commit或删除的half消息,也就是说这些half消息没有被生产者确认到底是删除掉还是提交掉。因为可能因为网络原因,RocketMQ并没有收到订单系统发送过来的commit/rollback请求。

所以,针对这些状态不确定的half消息,超过一定时间后,RocketMQ就会回调订单系统的一个接口,确认下到底是打算commit这个half消息还是要delete掉?此时,订单系统可以根据订单状态做相应的处理,然后告知RabbitMQ结果。



通过上面这样一套消息事务机制,就可以保证我们的订单系统一旦成功执行了数据库操作,就一定能将消息投递到MQ中,这样就保证了生产者发送消息一定不会丢失。

2.2 MQ侧

我们再来看下RocketMQ侧怎么保证消息不丢失。

其实通过第一节的分析,我们已经知道,RocketMQ侧存在两种消息丢失的情况:

  1. 消息写入到了OS Cache中,并已返回给Producer写入成功的响应,数据还未刷到磁盘,但MQ挂了;
  2. 数据已经刷到了磁盘上,Producer也收到了成功响应,但是磁盘坏掉了。

刷盘方式

针对第一种情况,默认情况下RocketMQ是异步刷盘,也就是说只要消息写入到了OS Cache,就会响应生产者成功。 所以如果一定要确保MQ侧零丢失的话,可以调整RocketMQ的刷盘策略,修改Broker的配置文件,将其中的flushDiskType配置设置为:SYNC_FLUSH,也就是同步刷盘

所以,调整为同步刷盘之后,生产者写入MQ的每条消息,只要MQ响应成功了,那么消息就是已经进入磁盘文件了。

数据同步

针对第二种情况,必须有Slave-Broker从Master-Slave同步数据,而且只有当Slave-Broker同步数据成功,才能认为消息写入成功。

这样一来,但凡一条消息写入成功,此时主从Broker上都有这条数据了,即使Master-Broker的磁盘坏了,Slave-Broker上至少还是有数据的,那数据也不会因为磁盘故障而丢失了。

对于基于DLedger技术和Raft协议构建的主从同步架构,只要MQ侧响应消息写入成功了,那就代表着数据已经通过Raft协议同步给了超过半数的Follower,所以在这种场景上,RocketMQ天然保证消息不会丢失。

2.3 消费者侧

最后,我们来看下消费者侧是怎么保证消息不丢失的。

之前说过了,如果消息者消费完消息,立即提交了消息的offset,然后还没处理完自身的逻辑就挂掉了,那么就会出现消息丢失的现象。

但是,对于RocketMQ而言,是消费者处理完自身业务逻辑后,再提交给Broker响应。所以即使此时系统崩溃了,没有响应成功,也没有关系,因为MQ侧会认为没有消费成功,会再次发送消息。

此时,消息者侧要做的就是控制好消费接口的幂等性,这个我们后面会讲到。

Consumer默认的消费模式,是必须处理完一批消息,才会返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS这个状态标识,告诉Broker消息都处理结束了,提交offset到Broker去。 所以需要特别注意,不能在代码中对消息进行异步的处理,也就是不能没处理完自身业务逻辑,就返回响应。

三、消息事务原理

RocketMQ的消息零丢失方案,最核心的就是生产者侧的事务消息机制,其本质是通过CommitLog、CosumeQueue这套存储机制来做的,half消息其实是写入到了Broker内部的Topic中。

3.1 Half消息原理

以订单系统为例,正常情况下,当订单系统发送一个通知消息给RocketMQ时,是指定这个通知消息的Topic为order_topic,然后最终定位到的是某台Broker服务器上的MessageQueue对应的ConsumeQueue。

但是如果这个通知消息是half消息,那么这个消息的offset并不会保存到order_topic对应的ConsumeQueue中,而是保存到一个名为RMQ_SYS_TRANS_HALF_TOPIC的内部Topic的ConsumeCQueue中,如下图:



可以看到,消费者(积分系统)订阅的是order_topic,而由于“支付成功通知消息”是个half消息,所以它在CommitLog中的偏移量offset是写入到内部RMQ_SYS_TRANS_HALF_TOPIC对应的ConsumeQueue中,所以half消息对于消费者实例来说是不可见的。

3.2 回调原理

如果订单系统没有对half消息进行commit或rollback,RocketMQ会去回调生产者的接口。那么RocketMQ怎么知道要回调哪些half消息呢?

事实上,RocketMQ后台有个定时任务,会去扫描RMQ_SYS_TRANS_HALF_TOPIC这个Topic中的half消息,如果发现某个half消息超过了一定时间还没被commit或rollback,它就会去回调生产者的接口,确认到底是commit还是rollback:



RocketMQ最多回调15次,如果15次之后那个half消息还没办法确认最终状态,就会默认对其rollback。

3.3 commit原理

如果生产者最终对half消息执行commit请求,那RocketMQ的底层是如何实现的呢?

事实上,RocketMQ接受到commit请求后,会往一个名为OP_TOPIC的内部Topic中写入一条OP记录,标记half消息已经是commit状态了。接着,会把RMQ_SYS_TRANS_HALF_TOPIC中的half消息offset写入到order_topic的ConsumeQueue里去,然后积分系统就可以看到这条消息,并进行消费了,如下图:



3.4 rollback原理

rollback原理和commit原理是一样的,如果生产者最终对half消息执行了rollback请求,RocketMQ的底层并不会真的把half消息给删除掉,而是在内部OP_TOPIC对应的ConsumeQueue中写入一条OP记录,标记half消息已经是rollback状态了:



四、总结

本章,我们对消息丢失的三类场景进行分析,并给出了一套消息零丢失的全链路解决方案,对RocketMQ中的事务消息机制原理进行了详细讲解。

在业务系统中,使用事务消息机制会大大降低吞吐量,所以一般建议,对于涉账类以及核心数据相关的交易链路或系统,可以采用上述这套消息零丢失方案。而对于其它大部分没那么核心的场景和系统,其实即使丢失一些数据,也不会导致太大的问题,不建议采用这套方案。

一般来说,对于大多数系统,生产者通过同步发送消息+反复重试的方式,就可以做到99%场景下的消息可靠投递。

正文到此结束
本文目录