消息丢失的场景分析

案例: 订单系统发送支付成功消息后,红包系统没有发出红包

按理来说，订单系统在完成支付之后，会推送一条消息到RocketMQ里去，然后红包系统会从RocketMQ里接收那条消息去给用户发现金红包

但是从订单系统和红包系统当天那个时间段的日志来看，居然只看到了订单系统有推送消息到RocketMQ的日志，但是并没有看到红包系统从RocketMQ中接收消息以及发现金红包的日志。

订单系统在接收到订单支付成功的通知之后，必然会去推送一条订单支付成功的消息到MQ的，那么在这个过程中，会出现丢失消息的问题吗？

其实答案是显而易的，有可能会丢失举一个比较常见的例子，比如订单系统在推送消息到RocketMQ的过程中，是通过网络去进行传输的，但是这个时候恰巧可能网络发生了抖动，也就是网络突然有点问题，导致这次网络通信失败了。于是这个消息必然就没有成功投递给MQ

还有没有其他的原因可能会导致订单系统推送消息到MQ失败的？那是相当的多了，比如MQ确实是收到消息了，但是他的网络通信模块的代码出现了异常，可能是他内部的网络通信的bug，导致消息没成功处理。

或者是你在写消息到RocketMQ的过程中，刚好遇到了某个Leader Broker自身故障，其他的Follower Broker正在尝试切换为LeaderBroker，这个过程中也可能会有异常。类似的问题可能还有其他的。

所以首先我们在使用任何一个MQ的时候，无论是RocketMQ，还是RabbitMQ，或者是Kafka，大家都要明确一点：不一定你发送消息出去就一定会成功，有可能就会失败，此时你的代码里可能会抛出异常，也可能不会抛出异常，这都不好说，具体要看到底什么原因导致的消息推送失败。

即使我们的订单系统成功的把消息写入了MQ，此时我们就可以想当然的认为你写成功了，消息就一定不会丢失了吗？

这个也是未必的，我们来分析一下为什么因为通过之前的RocketMQ的底层原理的分析，我们现在都明确了一点，就是你的消息写入MQ之后，其实MQ可能仅仅是把这个消

息给写入到page cache里，也就是操作系统自己管理的一个缓冲区，这本质也是内存

可能你认为写成功了一个消息，但是此时仅仅进入了os cache，还没写入磁盘呢。

然后这个时候，假如要是出现了Broker机器的崩溃，大家思考一下，机器一旦宕机，是不是os cache内存中的数据就没了？我们看下图

Broker把消息写入os cache之后，其实操作系统自己在一段不太确定的时间之后，他自己是会把数据从内存刷入磁盘文件里去的我们看下图

假设现在我们写入MQ的一条消息已经稳稳进入Broker所在机器的磁盘文件里了，大家觉得这个时候数据一定不会丢失吗？显然不能想的那么简单，因为如果你的磁盘出现故障，比如磁盘坏了，你上面存储的数据还是会丢失。

如果大家注意留意近两年的一些技术行业的不起眼的新闻，就会知道，有的互联网公司就是把数据存储在服务器的磁盘上，但是因为没有做完善的冗余备份，结果机器磁盘故障就导致那个互联网公司运营几年的核心数据都没了，找不回来了，大量的投资都打了水漂，血淋淋的教训。

所以如果消息进入了broker机器的磁盘之后，万一你实在是点儿背，赶上机器刚好磁盘坏了，可能上面的消息也就都丢失了我们看下图，清晰的标识出来，磁盘坏了也会导致上面存储的数据丢失。

即使红包系统这个时候顺利从MQ里拿到了一条消息，然后他就一定能安稳的把现金红包发出去吗？

这也是未必的。要解释这个问题，我们就要牵扯到消息的offset这个概念了。

之前其实我们已经给大家在底层原理分析的部分详细解释了MQ底层的存储结构，包括消息的offset的概念说白了，offset就是代表了一个消息的标识，代表了他的位置

假设现在有两个消息，offset分别为1和2

现在我们假设红包系统已经获取到了消息1了，然后消息1此时就在他的内存里，正准备运行代码去派发现金红包呢，但是要注意，此时还没派发现金红包

默认情况下，MQ的消费者有可能会自动提交已经消费的offset，那么如果此时你还没处理这个消息派发红包的情况下，MQ的消费者可能直接自动给你提交这个消息1的offset到broker去了，标识为你已经成功处理了这个消息，我们看下图。

接着恰巧在这个时候，我们的红包系统突然重启了，或者是宕机了，或者是可能在派发红包的时候更新数据库失败了，总之就是他突然故障了，红包系统的机器重启了一下，然后此时内存里的消息1必然就丢失了，而且红包也没发出去

可以通过重试机制和备忘录模式多次发送失败后本地存储后期进行消息补偿

消息到达mq,rocketmq丢消息,当使用异步刷盘时可能消息对于的commit log还在page cache中未刷新到磁盘此时broker的物理机宕机了重启导致page cache中数据丢失,

此时我们可以通过冗余备份磁盘的方式保证尽量丢少的消息

消费策略修改为手动提交ack，业务逻辑处理完了之后在进行手动提交offset。，还有一种就是记录到本地消息表中，失败的，然后下次从本地消息记录表中查询出来继续进行执行