前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >RocketMQ的消息是怎么丢失的

RocketMQ的消息是怎么丢失的

作者头像
HUC思梦
发布2020-10-26 11:45:23
7300
发布2020-10-26 11:45:23
举报
文章被收录于专栏:HUC思梦的java专栏

前言

通过之前文章的阅读,有关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的消息丢失问题是怎么解决的呢,欢迎大家留言和王子一起讨论。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2020-10-12 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 订单系统推送消息过程中会丢失消息吗?
  • MQ接收到消息后,自己会把消息弄丢吗?
  • 积分系统消费到了消息就能保证消息的不丢失了吗?
  • 总结
相关产品与服务
消息队列 TDMQ
消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档