我擦，RocketMQ的tag还有这个“坑”！（三）

2.2.2 客户端没有拉取到合适的消息位点提交机制

客户端如果没有拉取到合适的消息，例如全部被tag过滤了，在DefaultMqPushConsumerImpl的PullTask中定义了处理方式，具体如下所示：

 
其关键代码在correctTasOffset中，具体代码请看：

 
核心要点：如果此时处理队列中的消息为0时，则会将下一次拉取偏移量当成位点，而这个值在服务端进行消息查找时会向前驱动，代码在DefaultMessageStore的getMessage中：

 
故从这里可以看到，就算消息全部过滤掉了，位点还是会向前驱动的，不会造成大量积压。

2.2.3 消息拉取时会附带一次位点提交

其实RocketMQ的位点提交，客户端提交位点时会先存储在本地缓存中，然后定时将位点信息一次性提交到Broker端，其实还存在另外一种较为隐式位点提交机制：

 
即在消息拉取时，如果本地缓存中存在位点信息，会设置一个系统标记:FLAG_COMMIT_OFFSET,该标记在服务端会触发一次位点提交,具体代码如下：

 
2.2.4 总结与验证
综上述所述，使用TAG并不会因为对应tag数量比较少，从而造成大量积压的情况。

为了验证这个观点，我也做了一个简单的验证，具体方法是启动一个消息发送者，向指定topic发送tag B的消息，而消费者只订阅tag A,但消费者并不会出现消费积压，测试代码如下图所示：

 
查看消费组积压情况如下图所示：

文章转自公众号：中间件兴趣圈