1、问题现象
某一天,项目组一个同事向我反馈,他们使用公司的数据同步产品将MySQL数据同步到MQ集群,然后使用消费者将数据再同步到ES,反馈数据同步延迟严重,但对应的消费组确没有积压,但最近最近几分钟的数据都没有同步过来。
那问题来了,消费端没有消费积压,而且通过查看数据同步平台该通过任务的同步状态,同样显示没有积压,那是为什么呢?
遇到这个问题,我们应该冷静下来,分析一下其大概的数据流向图,梳理后如下图所示:
通过初步的诊断,从数据同步产品查看Binlog同步无延迟、MQ消费无积压,那为什么最终Es集群中的数据与MySQL有高达几分钟的延迟呢?
2、问题排查
根据上图几个关键组件数据同步延迟的检测,基本就排除了数据同步组件、MQ消费端本身消费的问题,问题的症结应该就是数据同步组件成功将数据写入到MQ集群,并且MQ集群返回了写入成功,但消费端并没有及时感知这个消息,也就是说消息虽然写入到MQ集群,但并没有达到消费队列。
因为如果数据同步组件如果没有写入成功,则MySQL Binlog日志就会出现延迟。但如果是MQ消费端的问题,则MQ平台也会显示消费组积压。
那为什么消息服务器写入成功,但消费组为什么感知不到呢?
首先为了验证上述结论是否正确,我还特意去看了一下主题的详细信息:
查看主题的统计信息时发现当前系统的时间为19:01分, 但主题最新的写入时间才是18:50,两者之间相差将近10分钟。
备注:上述界面是我们公司内部的消息运营管理平台,其实底层是调用了RocketMQ提供的topicStatus命令。
那这又是怎么造成的呢?
在这里我假设大家对RocketMQ底层的实现原理还不是特别熟悉,在这样的情况下,我觉得我们应该首先摸清楚topicStatus这个命令返回的minOffset、maxOffset以及la