RabbitMQ 双机系统偶尔丢失消息问题排查

实话说起来,这个问题,实际是一个非常低级的错误导致的,算不得什么高深的技术问题。但是在排查的过程中,却是费了好大的功夫,死了不少脑细胞。所以也值得记录一下,算作给大家提个醒,或许可以帮大家节省点时间。

情况是这样的,我们的一个项目,采用双机热备的模式部署了一套应用系统,这个应用系统和上层的业务系统之间通过RabbitMQ进行消息交互。上层业务系统发布业务数据,应用系统订阅业务数据并处理。由于是双机热备模式,所以程序上还做了处理,只有主机负责订阅业务数据,备机不会进行订阅。

在开发测试阶段发现,应用系统偶尔会出现收不到上层业务系统发布的业务数据的情况。经过检查,RabbitMQ的队列中没有消息堆积,这说明要么上层业务系统没有将消息放入队列中,要么订阅过程中发生了消息丢失。

根据上面的判断,第一反应是网络问题,于是对网络进行了检测,排除了网络质量的问题。然后怀疑是我们业务系统没有正确处理订阅消息导致的,于是又在主机上进行了网络抓包,发现确实没有收到该订阅的消息。 既然网络没有问题,又确实没有收到消息,所以进一步怀疑是上层系统的问题,结果上层系统排查了半天,确认消息确实发布到了队列中。

于是问题就来了,既然消息进入了队列,队列里消息也被消费了,但为啥业务系统收不到? 于是大家一顿头脑风暴,最后突然间想到,双机系统出了问题? 该被主机处理的消息,被备机订阅到了?导致主机消息丢失?

按照这个思路一查,发现确实是这样的。原本不应该订阅和消息消息的备机居然收到了消息。根据设计这不应该发生。仔细一查,原来是程序出了BUG.

最后总结下来,虽然是一个低级的程序bug,但是排查过程中,浪费了太多的时间,主要是大家都没有考虑到双机系统会出现备机消费消息的可能性。 这个问题以后在双机或者多机系统中,应该最为一个排查项来考虑,以免走弯路。

相关推荐
PingCAP7 小时前
善战者无赫赫之功:消费金融核心系统的数据库选型与升级路径
数据库·分布式·架构
库库的数据库笔记9 小时前
金融核心交易系统的数据库国产信创改造该如何做?
大数据·数据库·分布式·mysql·oracle·金融·数据库架构
爱吃火鸡面呀14 小时前
深入理解 Spark RDD:五大特性与实战解析
大数据·分布式·spark
Linux实战笔记15 小时前
记一次消息队列选型对比线上排查:Kafka/RabbitMQ/Pulsar 技术选型
kafka·rabbitmq·高并发·pulsar·消息队列选型
Norris Huang16 小时前
Kafka Connect 与 Flink CDC 写入 Iceberg:Upsert 的代价,以及 S3 Tables 的真正价值
分布式·flink·kafka
张彦峰ZYF16 小时前
一条消息的丢与重:Kafka 与 RabbitMQ 可靠投递的确认、位点、死信与幂等全链路
后端·kafka·消息队列·rabbitmq·isr·解耦与削峰·丢失与重复
我就是不信16 小时前
集群高并发环境下如何保证分布式唯一全局ID生成?
分布式
黄俊懿2 天前
【架构师从入门到进阶】第六章:服务集群优化——第八节:线程数公式
java·服务器·数据库·分布式·性能优化·架构·系统架构
大菠萝爱上小西瓜2 天前
基于 Spark + Iceberg 湖仓一体的 Netflix 流媒体用户行为全链路数仓与 ALS 智能推荐决策系统(含穿透下钻大屏)
大数据·分布式·spark
吴建旭 智宅焕2 天前
智能家居售后服务体系的架构设计:分布式售后风险的集中式兜底方案
分布式·智能家居