Skip to Main Content

消费者提交位点回退检查

巡检规则​

本文中提及的 RocketMQ Copilot 术语是 AutoMQ Copilot for RocketMQ 的简称，均特指安托盟丘（杭州）科技有限公司面向 Apache RocketMQ 设计实现的消息队列智能辅助运维系统。

检测数据源​

ConsumerGroup 消费位点回退检查的检测数据源是查看 ConsumerGroup 消费位点历史更新记录，判断是否出现了回退的风险。

检测周期​

  • 每 10 分钟一次。
  • 不可关闭。

异常检测逻辑​


检查客户端提交位点比服务端已经持久化保存的位点小，则产生异常事件。

事件和风险​

RocketMQ Copilot 系统巡检会对检测不通过的规则产生异常事件和风险，异常事件遵循 概述▸ 。

异常事件​

异常风险​

  • 关联的风险类型：消费者位点回退。

风险分析​

正常情况下，消费者对指定队列提交的位点总是不小于 Broker 上对该队列的消费位点的。如果 Broker 上对当前的 Consuemer Group 和队列已经有消费记录存在，且提交的位点比消费记录中的位点小，在 Broker 上就会出现 [NOTIFYME]update consumer offset less than store 的日志报错。

一个典型场景：同一个 Consumer Group 下，ConsumerA 将队列较新的消费位点更新到了 Broker，随后发生的负载均衡导致 ConsumerB 获取了这个队列的所有权，但是在 ConsumerB 获取服务端消费位点时，服务端还没完成对 ConsumerA 汇报上来位点的更新，等到 ConsumerB 的位点更新上来时，ConsumerA 汇报上来的位点已经完成了更新，此时在服务端看来，就发生了位点回退。

位点回退会带来大量的重复消费，如果业务没有做消防幂等处理，则可能造成逻辑错误。

可以根据日志中的 requestOffset（试图更新的位点） 和 storeOffset（服务端存储的位点） 来确定位点回退的大小，如果回退的值比较小则不会造成太大影响。如果比较大，可以查看是否使用 mqadmin resetOffsetByTime 重置过服务端的消费位点。

运维建议​

建议 1：生产环境做好消息幂等处理​

生产环境建议消费者业务逻辑根据消息唯一键做好幂等处理，降低因系统异常或者运维错误导致的消费位点回退的影响。