面试官：RocketMQ一个消费组内订阅同一个主题不同的TAG为什么会丢消息

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

1、MQ底层数据结构设计之巧妙

---

RocketMQ专门按照Topic为每一个topic建立索引，方便消费端按照topic进行消费，其具体实现为消息队列。

在RocketMQ中，ConsumeQueue的引入并不是为了提高消息写入的性能，而是为消费服务的。

消息消费队列中的每一个条目是一个定长的，设计极具技巧性，其每个条目使用固定长度（8字节commitlog物理偏移量、4字节消息长度、8字节tag hashcode），这里不是存储tag的原始字符串，而是存储hashcode。

目的就是确保每个条目的长度固定，可以使用访问类似数组下标的方式来快速定位条目，极大的提高了ConsumeQueue文件的读取性能，这样根据消费进度去访问消息的方法为使用逻辑偏移量logicOffset * 20即可找到该条目的起始偏移量(consumequeue文件中的偏移量)，然后读取该偏移量后20个字节即得到了一个条目，无需遍历consumequeue文件。

2、消息过滤实现机制

---

消费端队列存储的是 tag 的 hashcode，众所周知，不同的字符串得到的hashcode值可能一样，故在服务端是无法精确对消息进行过滤的，所以在RocketMQ中会进行两次消息过滤。

当客户端向服务端拉取消息时，服务端在返回消息之前，会先根据hashcode进行过滤，然后客户端收到服务端的消息后，再根据消息的tag字符串进行精确过滤。

上面的原理很好理解呀，那为什么会丢失消息呢？这其实和消息队列负载机制有关.

在RocketMQ中使用集群模式消费时，同一个消费组中的多个消费者共同完成主题中的队列的消费，即一个消费者只会分配到其中某几个队列，并且同一时间，一个队列只会分配给一个消费者，这样结合上面的的过滤机制，就会明显有问题，请看示例图：

其问题的核心关键是，同一个tag会分布在不同的队列中，但消费者C1分配到的队列为q0,q1，q0,q1中有taga和tagb的消息，但tagb的消息会被消费者C1过滤，但这部分消息却不会被C2消费，造成了消息丢失。

读者福利

由于篇幅过长，就不展示所有面试题了，感兴趣的小伙伴

更多笔记分享

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**