前言
通过之前文章的阅读，有关RocketMQ的底层原理相信小伙伴们已经有了一个比较清晰的认识。
那么接下来王子想跟大家讨论一个话题，如果我们的项目中引入了MQ，势必要面对的一个问题，就是消息丢失问题，今天我们就来聊聊消息是怎么丢失的。
现在假设我们的业务是这样的，用户通过订单系统下了一个订单，订单系统完成支付后会发送消息给RocketMQ，然后积分系统会从RocketMQ中消费消息，去给用户增加积分，如下图：
但是突然有一天有用户反映，支付订单之后，自己的积分并没有增长，这是为什么呢？
经过排查日志，我们只发现了推送消息给MQ的日志，而没有发现积分系统消费这条消息的日志，这就导致了积分系统并没有给用户发放积分。
也就是说，消息在传输过程中丢失了。
在系统的核心链路中，如果发生消息丢失的问题，可能会产生恶劣的后果，为了解决此类问题，我们必须弄明白什么时候会发生消息丢失。
订单系统推送消息过程中会丢失消息吗？
我们先来看一下整个流程的第一步，订单系统在支付成功之后，一定会把支付成功的消息推送给MQ，那么在这个推送的过程中，消息可能丢失吗？
答案是肯定的，一定会存在消息丢失的情况。
比较常见的情况就是网络抖动，在推送消息这一过程中是通过网络进行通信的，那么这个时候如果恰巧网络出现了故障，导致通信失败了，那么这个消息必然就不会成功的推送到MQ中。
那除了网络抖动外，还有没有其他的情况导致推送失败呢？
其实情况有很多，比如MQ成功接收到了消息，但是MQ本身的网络模块的代码出现了异常，可能是内部实现的bug,导致消息没有成功处理。
或者当我们推送消息给一个MQ的主从集群的时候，刚好遇到Leader节点出现故障，其他的Follower正在尝试切换为Leader，这个过程中也可能导致消息丢失。
类似的问题还有其他的。
所以我们首先要明确一点，无论我们使用任何MQ中间件的时候，你发送出的消息都不一定能成功，而失败的时候有可能会在你的代码里发生异常，也有可能不会抛出异常，具体要看什么情况导致的发送失败。
MQ接收到消息后，自己会把消息弄丢吗？
接下来假设我们订单系统推送到MQ这一过程没有任何问题，消息成功到达了MQ中，此时订单系统会认为消息写入成功了，那么这时候消息就一定不会丢失了吗？
答案是否定的，这个时候也不能保证消息的不丢失，我们来分析一下。
通过之前文章的了解，相信大家都还记得，当消息写入到MQ后，MQ会把消息先写入到os cache，也就是操作系统的缓存区中，本质也是内存，如下图：
也就是说，你认为发送成功的消息，可能只存在于内存中，还没到磁盘中。
那么如果这个时候机器宕机了，os cache中的消息数据将会跟着丢失掉，是不是这个理。
那么现在假设消息已经刷新到磁盘上了，是不是就可以保证万无一失了呢？
显然这个时候也是不能完全保证的，因为虽然你把数据保存到了磁盘中，但是如果磁盘发生了故障，数据还是会丢失掉。
如果大家平时有了解一下新闻热点，会听说过某某互联网公司，由于数据存储在磁盘上没有冗余备份，结果磁盘发生故障导致好多年的核心数据全部丢失，大量工作都功亏一篑，这就是血淋淋的教训。
积分系统消费到了消息就能保证消息的不丢失了吗？
那么到现在，经历了重重困境，假设积分系统终于能够消费到这条消息了，那么它就能安稳的把积分正常的发放给用户吗？
答案依然是否定的。
看过之前文章的小伙伴们应该还记得消费者在进行消费时，是有一个offset的概念的。
这个offset说白了就是个进度标识，让MQ知道消费者消费到了哪，下次好接着向下消费。
现在假设我们有两条消息，offset为1和2。
假设我们的积分系统接收到了消息1，那么消息1就在积分系统的内存中，正要准备给用户发放积分。
而默认情况下，消费者会自动提交已经消费的消息的offset，所以当积分系统获取消息后，可能直接就把消息1的offset提交给了MQ，标识为已经处理了这条消息。
那么此时，如果积分系统突然宕机，还未发放积分给用户，那么这条消息1自然就丢失了，因为MQ已经把他标记成了已处理，实际积分系统还未处理。
所以消费者获得消息后也是可能发生消息丢失的。
总结
好了，看过今天的文章，相信小伙伴们对于RocketMQ的消息是怎么丢失的会有一个更深刻的印象。
总结起来就是以下几点：
1.生产者发送消息到MQ这一过程导致消息丢失
2.MQ自己发生故障导致消息丢失
3.消费者拿到消息后，由于操作不当导致消息丢失
所以任何的技术引入生产环境都是有风险的，引入前我们一定要做好功课。
今天的文章就说到这，小伙伴们可能会问王子，聊了这么多，到底应该如何解决掉消息丢失的问题呢？
别急，我们下篇文章就会有解决方案了。
那么小伙伴们针对MQ的消息丢失问题是怎么解决的呢，欢迎大家留言和王子一起讨论。
往期文章推荐：