案例分享|生产环境MQ集群一个非常诡异的消费延迟排查

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