Rocketmq tag过滤机制

[2335119327]

看了下源码，在broker处理拉取消息请求时，会根据consumerQueue的tag的hashCode进行一次过滤
然后消息拉取到本地会在根据原始的消息的tag进行精确过滤
但为什么不在broker全都处理好呢？
消息会从broker取出来，此时就可以进行tag的精确过滤呀，感觉好像没必要再弄到consumer本地进行二次过滤

不知道有没有大佬能解答一下！万分感觉~

[2335119327]

万分感谢~

[cserwen]

cq 只存储了消息 tag 的 hashcode 信息，没有具体的 tag 值，如果想要在服务端精确过滤，必须要decode msg，这样就会增加服务端的计算压力，同时也会增加 pullMessage 的时延，

因为客户端本身就要 decode 消息，因此将精确过滤放在客户端可以很好的利用资源，broker 负责快速初筛，消费者进行最终确认。这样可以避免 broker 端的计算瓶颈，同时让消费者在相对空闲时完成过滤操作。

你说的精确过滤，服务端也是支持的，不过要用 SQL 的方式去过滤，可以参考 ExpressionMessageFilter#isMatchedByCommitLog() 方法

[2335119327]

感谢解答~

[genglongsir]

cq 只存储了消息 tag 的 hashcode 信息，没有具体的 tag 值，如果想要在服务端精确过滤，必须要decode msg，这样就会增加服务端的计算压力，同时也会增加 pullMessage 的时延，

因为客户端本身就要 decode 消息，因此将精确过滤放在客户端可以很好的利用资源，broker 负责快速初筛，消费者进行最终确认。这样可以避免 broker 端的计算瓶颈，同时让消费者在相对空闲时完成过滤操作。

你说的精确过滤，服务端也是支持的，不过要用 SQL 的方式去过滤，可以参考 ExpressionMessageFilter#isMatchedByCommitLog() 方法

你好，我发现使用byTag过滤了消息，那么消息的trackType显示为CONSUMED_BUT_FILTERED
而使用bySql过滤了消息，那么消息的trackType显示为CONSUMED
请问一下，为什么会有这种区别

[cserwen]

@genglongsir
这个只是控制台的解析逻辑，rmq 默认没有记载每条消息的消费结果，只能根据消费位点、消息内容、订阅信息粗略计算一个状态，

状态计算应该是没有考虑 bysql 的情况，错误展示了 consumed，你可以看下源码，看下是否可以优化~