让~学习~成为一种习惯（橡 皮 人の技术博客）

consumer-1不要Tag-2的消息，于是队列1、2中所有Tag-2的消息就被过滤，也就是被丢掉了，同样consumer-2不要Tag-1的消息，那么队列3、4中所有Tag-1的消息也被丢掉了，这就造成了消息丢失的问题。生产环境基本都是由多个consumer组成消费者组来消费的，那么对于不了解订阅关系的同学，在使用上很容易出现错误，在RocketMQ中，订阅关系是按照消费者组+Topic+tag粒度设计的，也就是一个订阅关系=某消费者组+某Topic+某tag。

它的原理本质上和Tag过滤一样，不过因为ConsumeQueue消息的结构中没有Property，所以SQL属性过滤需要从commitlog里面获取消息，再解析其中的属性，最后再做SQL匹配，不匹配的消息就过滤掉，不过它没有哈希碰撞的问题，消费者也不会对其进行二次校验。我们知道消费者订阅到某个Topic后，就能从Broker这边拉取对应的消息消费，但是消费者可能只对这个Topic下的部分消息感兴趣，这时候就需要对Topic下的消息进行再次过滤了，那么RocketMQ是如何做的呢？但是哈希碰撞怎么办？

前面两篇我们介绍了RocketMQ的延迟消息和事务消息实现原理，今天我们就介绍最后一个高级消息类型——顺序消息。之前在RocketMQ第4讲——生产者一篇中大致聊了一些顺序消息的相关东西，这篇就从发送、存储和消费阶段具体介绍下。

在发送事务消息时，首先会向Broker发送一条“half消息”（即半消息），此时的半消息还不能被消费者消费到，接下来，在半消息发送成功后，应用程序通过本地事务的执行情况来确定是否要提交该事务消息，如果本地事务执行成功，那么就会通知Broker提交，这时消费者就能消费到这条消息了；回滚事务消息：如果本地事务执行失败，程序会通知Broker回滚该事务消息，状态由“prepared”改为“rollback”，并将该消息删除，从而保证不被消费者消费到。如果执行成功，则通知Broker提交该事务消息。

上面我们讲过，RocketMQ 4.x发送延迟消息的时候，会先把消息暂存到一个中间队列，然后扫描是否到期，到期后才会被投递到真正的Topic中，这个方案的局限性就是每个队列的延迟时间必须是相同的。假如支持任意消息也用队列的方式存的话，如果队头的消息延迟时间比较长，就会阻塞住后面的消息投递，久而久之延迟队列长度就会越来越大。Broker接收延迟消息，他需要控制没到时间的消息不会被消费者消费到，但是消息的量级可能很大（十万、百万、千万），一条消息对应一个”闹钟“的管理机制，神仙来了也扛不住。

在第一篇文章中提到过一个“nameServ“的东西，这里我们再把架构图粘过来：它也是RocketMQ的核心组件之一，从上图我们不难理解，生产者和消费者要通过nameServ才能直到Broker的位置，这个组件全称叫nameServer，即命名服务。那么它和Broker、Producerr和Consumer之间是什么关系呢？

前两篇文章我们已经知道了消息是如何存储和发送的，这篇我们就学习下消费者消费的一些细节。消息是存储在Broker上的，那么消费者是如何获取的呢？是Broker主动推给消费者的还是消费者主动去Broker上拉的呢？

过了个年懈怠了，距离上篇文章已经过去了40多天😰，好在已经调整好了状态，那么从今天开始立个flag：尽自己最大努力保证每周至少更新总结一篇博客✊小伙伴们也要一起共同加油进步哈😄。那么这篇文章就把目光转移到生产者这边，RocketMQ官方把生产者能发送的消息类型分为4类：普通消息（批量）顺序消息定时/延时消息事务消息我们一起来看看。

经过前两篇，我们已经总览了一个企业级消息队列的架构，也知晓了消息队列的两个基础模式（点对点和发布-订阅），还有消费者组等的一些概念。这里再粘一下RocketMQ的整体架构：我们知道消息队列很关键的一个功能就是削峰添谷，简单地说就是把“超额”的流量先存起来，然后让系统平缓、匀速地从消息队列里面拉取消息来消费，那么这就需要保证消息存储的可靠性了，这也是我们今天的重点——存储（Broker）。

上篇我们介绍了市面上消息队列的基本信息和RocketMQ整体架构，这里再粘一下：通过上篇我们知道同一个topic下的消息在不同消费者组之间可以全量消费，而且消费进度又可以不一样，而且同一个消费者组内的消费者在集群模式下可以负载均衡的消费消息，在广播模式下又可以全量消费这些消息，那么这是怎么实现的？是将消息复制了多份吗？这就涉及消息队列的两种模式了。

今天开始就系统的学习和总结下消息队列，市面上消息队列的设计基本八九不离十，我对RocketMQ相对熟悉一点，所以就从RocketMQ入手，在知晓RocketMQ的大体设计后对其它消息队列也就手到擒来了。