RocketMQ消息过滤与查询

最新推荐文章于 2024-08-13 16:19:33 发布

ph3636

最新推荐文章于 2024-08-13 16:19:33 发布

阅读量3k

点赞数

分类专栏： RocketMQ 文章标签： RocketMQ

本文链接：https://blog.csdn.net/ph3636/article/details/89066990

版权

RocketMQ的消息过滤在Consumer端完成，基于Tag或SQL92表达式。Tag过滤根据消息Tag的哈希值匹配订阅请求，而SQL过滤利用BloomFilter优化效率。消息查询支持按照MessageId和Message Key，MessageId查询通过解析地址和偏移量直接获取，Message Key查询依赖于IndexFile索引文件。

摘要由CSDN通过智能技术生成

消息过滤

RocketMQ分布式消息队列的消息过滤方式有别于其它MQ中间件，是在Consumer端订阅消息时再做消息过滤的。RocketMQ这么做是还是在于其Producer端写入消息和Consomer端订阅消息采用分离存储的机制来实现的，Consumer端订阅消息是需要通过ConsumeQueue这个消息消费的逻辑队列拿到一个索引，然后再从CommitLog里面读取真正的消息实体内容，所以说到底也是还绕不开其存储结构。其ConsumeQueue的存储结构如下，可以看到其中有8个字节存储的Message Tag的哈希值，基于Tag的消息过滤正式基于这个字段值的。

主要支持如下2种的过滤方式

(1) Tag过滤方式：Consumer端在订阅消息时除了指定Topic还可以指定TAG，如果一个消息有多个TAG，可以用||分隔。其中，Consumer端会将这个订阅请求构建成一个 SubscriptionData，发送一个Pull消息的请求给Broker端。Broker端从RocketMQ的文件存储层—Store读取数据之前，会用这些数据先构建一个MessageFilter，然后传给Store。Store从 ConsumeQueue读取到一条记录后，会用它记录的消息tag hash值去做过滤，由于在服务端只是根据hashcode进行判断，无法精确对tag原始字符串进行过滤，故在消息消费端拉取到消息后，还需要对消息的原始tag字符串进行比对，如果不同，则丢弃该消