消息队列之消息过滤

众所周知，RocketMQ是支持消息过滤的，即发送消息时，可以给消息设置一个TAG。订阅主题的时候，可以设置只消费携带某些TAG的消息，起到消息过滤的作用。

RocketMQ中是把消息TAG通过哈希转换成了的long型，保存在了消息索引中。在订阅客户端拉取消息时，为了减少协议大小，减低报文长度，拉取协议中也只携带指定的若干TAG的哈希值，服务端接收到拉取请求时，在查找索引时，就直接过滤了不符合条件的索引。这里就会有一个问题，如果出现哈希冲突了，就会有错误的消息被客户端消费到。RocketMQ为了提高性能，并没有在服务端对消息进行反序列化，所以精准的二次过滤是在客户端完成。当客户端收到拉取结果后，会通过反序列化出来的消息内容，用TAG原始值再次过滤，保证过滤的准确性。

以上是RocketMQ消息过滤的基本做法，因为索引必须是固定大小的，这样才能通过偏移量，直接计算出索引的位置。所以在存储TAG时，要把TAG转换为固定长度，即通过哈希的方式转换成了long。这里会产生一个限制，即一条消息，只能携带一个TAG标签。

如果一条消息要携带多个TAG标签，又该如何做。

最简单想到的，就是TAG不做转换，也不存放在消息索引中了，拉取消息时，服务端把消息反序列化，直接通过消息内容中的TAG原始值进行过滤。该方法肯定不可取，对性能影响很大。所以我们还需要一种既可以支持单条消息多个TAG，也不影响性能的方案。

接下来是我的一个思考过程。

不影响性能，就必须利用到索引，在查找索引时就过滤掉绝大部分不符合条件的消息。那么问题就转换成了如何把多个TAG保存到固定长度的消息索引中？

即我们怎么把多个TAG映射到一个固定的长度上，并且映射后的结果，可以准确地、或几乎准确地判断出哪些TAG是符合条件的。

搜索大脑，首先想到的就是布隆过滤器，原始的布隆过滤器肯定无法满足，我们只采用其思想。我们把索引中的long看做一个64位的bitmap，每一位初始化为0。每个TAG通过n个哈希算法，映射的64位中的n位上。在拉取消息时，只需要采用相同的n个哈希算法，计算订阅设置的TAG映射的n个位置，如果这n个位置都为1，则说明该索引对应的消息可能包含该TAG，二次精准的过滤依旧在客户端进行；否则，一定不符合条件，直接过滤掉。

该方式可以满足我们的要求，但是每个tag都要计算n次哈希，会对消息保存和拉取都产生一定的性能影响。并且扩展性较差，如果把哈希算法放在客户端，则较难扩展。如果把哈希算法放在服务端，则拉取协议需要携带原始TAG，又会增大报文长度。

再继续搜索大脑，又想到了一个词，叫基因法。在好久好久以前，分库分表刚开始流行起来那会，几乎所有非“云分库分表”程序员都会遇到一个问题，我常用的查询条件有两个字段，一个主键、一个XX，我按照哪个字段进行分库分表呢？基因法就成为了其中一种解决方案，即主键的构造中，末N位由XX字段生成，即主键中包含了XX的基因。

我们从另一个角度来看，我们所有TAG生成的一个固定长度的值，如果可以准确过滤出不符合条件的TAG，是不是意味着我们生成的值一定包含了所有TAG的基因。

接着我们再看一组公式，假设有两个二进制数X和Y，如果X&Y=X，则X中所有值为1的位，在Y中一定也为1；反之不一定成立。也就可以说Y包含了X的所有基因。如何让一个二进制数包含另一个二进制数的所有基因呢？

很容易想到，利用按位或的方式，即只需要Y=S|X，其中S为任意二进制数。

所以，X&Y===X，当Y=S|X时，其中S为任意二进制数。

扩展一下，有二进制数集合P{P1,P2,P3......}，一定有（P1|P2|P3|......）&Pn===Pn。

回到我们的TAG中，我们依旧把TAG通过哈希转换为long，索引中保存所有TAG的哈希值按位或的结果。当拉取消息时，通过订阅设置的TAG哈希值与索引中的哈希值进行按位与操作，如果结果等于订阅设置的TAG哈希值，说明该索引对应的消息可能符合条件，二次精准过滤依旧在客户端来做；否则，一定不符合条件，直接过滤掉。

至此，简单说明了两种如何让RocketMQ单条消息支持多TAG的方案。实际都较为简单，实现起来也不复杂，两种我都已经做了实现，但是联想过程还是挺有意思，看似不相关的知识点，可能就会带来意想不到的灵感。

欢迎关注原创公众号：