Rocketmq 消息过滤简述

Rocketmq消息过滤是指在消息消费时，消费者Consumer可以对某一主题下的消息按照某种过滤规则进行过滤，只消费自己感兴趣的消息。Rocketmq同时支持在Broker端和Consumer端做消息过滤。

Broker端过滤

Broker端过滤只会将消息消费者感兴趣的消息发送给消息消费者，减少了无用消息的网络传递，提高了传输效率。

Broker端过滤更详细的又可以分为Tag过滤、表达式过滤、类模式过滤。

Tag过滤

说明：消息发送时可以指定该消息的Tag号，消息存储到CommitLog后会异步转发构建ConsumeQueue，ConsumeQueue条目中包含消息Tag的hashcode值，消费者消费消息会从broker拉取消息，拉取时指定消息必须带有目标Tag值，那么遍历ConsumeQueue条目时会判断条目中Tag的hashcode值是否等于目标Tag的hashcode值，如果相等，说明可能是消费者感兴趣的消息。但是，因为比较的是Tag的hashcode值，所以实际的Tag可能不一样，所以消息拉取到消费者端后还要比较Tag值，才能保证是消费者正真感兴趣的消息。

优点：仅仅根据ConsumeQueue就可以进行过滤，过滤完之后才去CommitLog拉取实际的消息内容返回给消费者，效率比较高。

缺点：消费者端需要做进一步的比对才可以确定是否是感兴趣的消息。

属性表达式过滤

说明：同样在消息发送时指定消息的扩展属性，消息存储到CommitLog，消息拉取时，根据Topic从ConsumeQueue中取出消息的偏移量之后，还需要根据偏移量去CommitLog中遍历，判断某个消息的属性是否匹配属性表达式，匹配才会返回消费者。

优点：可以设置多个自定义属性值，过滤可以做到多样化。并且属性值直接比较可以确保返回的消息都是消费者感兴趣的消息。

缺点：仍然需要遍历Topic下的所有消息，判断是否匹配属性表达式，有一定的开销。

类过滤

说明：在Broker端可以运行一个或者多个过滤服务器FilterServer，消费者可以自定义消息过滤实现类并将其上传至FilterServer，那么消费者的拉取命令会中间经过一层FilterServer，Broker返回的消息先在FilterServer端做一次过滤之后再返回消费者。

优点：过滤逻辑完全由消费者把控，想怎么过滤怎么过滤，只要在java类里面能实现出来就行。

缺点：需要运行java类，过滤类太多的情况下消耗Broker性能。

Consumer端过滤

说明：消息拉取回来后在Consumer端做过滤，不感兴趣的消息不消费。

优点：过滤逻辑完全由消费者把控。

缺点：大量不感兴趣的消息会传输到消费者端，白白占用带宽。