源码分析RocketMQ同一个消费组设置不一样tag，消息订阅失败问题

背景介绍

项目组使用阿里RocketMQ，对同一个消费组设置不一样的tag订阅关系，出现消息丢失的问题，本文从rocketmq源码研究消息发布与订阅原理，并分析致使该问题的缘由。

官方说明

• 告诉使用者：同一个消费组，必须保持订阅关系一致
• 为何？它没有说！只能从源码找答案

  

问题复现

1. 启动消费者1，消费组为group1，订阅topicA的消息，tag设置为tag1 || tag2
2. 启动消费者2，消费组也为group1，也订阅topicA的消息，可是tag设置为tag3
3. 启动生产者，生产者发送含有tag1,tag2,tag3的消息各10条
4. 消费者1没有收到任何消息，消费者2收到部分消息

先上结论

• 同一个消费组中，设置不一样tag时，后启动的消费者会覆盖先启动的消费者设置的tag
• tag决定了消息过滤的条件，通过服务端和客户端两层过滤，最后只有后启动的消费者才能收到部分消息

原理说明

消息如何保存

CommitLog

• 保存全部topic的原始消息
• CommitLog分为多个文件，每一个文件默认最大为1G
• 每条记录包括：消息长度和消息文本（消息体，属性，uid等等）
• 因每条消息长度不一致，每一个commitLog的记录长度也不一致

ConsumerQueue

• 保存某个Topic下某个Queue的索引信息
• 每条记录包括：消息在commitLog中的offset，消息大小，消息tag的哈希值
• 每条记录长度固定为20byte
• producer发送消息后，先保存到commitLog，再异步创建该条消息对应的topic + queue对应的ConsumerQueue索引
• 第三部分的Hash(tag)是服务端过滤消息的重要依据

consumer如何订阅消息

注册订阅信息

• consumer订阅时，会将订阅信息注册到到服务端
• 保存订阅信息的是Map类，key为topic，value主要是tag
• subVersion取当前时间。

  这里的key是topic，subVersion版本号，这两点很关键！后面有用到！

拉取消息并过滤

• 拉取消息时，首先从服务端获取订阅关系，获得tag的hash集合codeSet
• 而后从ConsumerQueue获取一条记录，判断记录的hashCode是否在codeSet中，以达到消息过滤的目的，决定是否将该消息发送给consumer
• 总之一句话：tag决定了消息是否发到客户端

消息过滤

服务端过滤

• 过滤：tag的hash值过滤
• 优势：
  • 减小没必要要消息占用流量
• 缺点：
  • Hash存在冲突，过滤不彻底准确

客户端过滤

• 服务端过滤存在不许确性，客户端再次精确过滤
• 客户度过滤：tag的字符串值作对比。不相等的不返回给消费者

缘由总结

• 同一个consumer group的订阅关系，保存在RebalanceImpl类的Map中。key为topic
• 不一样的消费者启动后，依次注册订阅关系，由于tag不同，致使Map中同一topic的tag被覆盖。好比：消费者1订阅tag1，消费者2订阅tag2。最后map中只保存tag2.
• 过滤的核心是是tag，tag被更新，过滤条件被改变。服务端过滤后只返回tag2的消息
• 客户端接收消息后，再次过滤。先启动的消费者1订阅tagA，可是服务端返回tag2，因此消费者1收不到任何消息。消费者2能收到一半的消息（集群模式，假设消息平均分配，另一半分给tag2）

源码分析

订阅关系数据结构

消费者1启动时注册的订阅关系

消费者2后启动覆盖订阅关系

服务端过滤时取出ConsumerQueue的Hash(tag)

对比消息的Hash(tag)和以前保存的订阅关系

客户端过滤