RocketMQ 简单介绍（一）

RocketMQ 简单介绍（一）

一、概述

1、介绍

​ Apache Alibaba RocketMQ 是一个消息中间件。消息中间件中有两个角色：消息生产者和消息消费者。RocketMQ 里同样有这两个概念，消息生产者负责创建消息并发送到 RocketMQ 服务器，RocketMQ 服务器会将消息持久化到磁盘，消息消费者从 RocketMQ 服务器拉取消息并提交给应用消费。

2、发展历史

• 2007年，阿里开始五彩石项目，Notify作为项目中交易核心消息流转系统，应运而生。Notify系统是
  RocketMQ的雏形。
• 2010年，B2B大规模使用ActiveMQ作为阿里的消息内核。阿里急需一个具有海量堆积能力的消息系
  统。
• 2011年初，Kafka开源。淘宝中间件团队在对Kafka进行了深入研究后，开发了一款新的MQ，MetaQ。
  2012年，MetaQ发展到了v3.0版本，在它基础上进行了进一步的抽象，形成了RocketMQ，然后就将其
  进行了开源。
• 2015年，阿里在RocketMQ的基础上，又推出了一款专门针对阿里云上用户的消息系统Aliware MQ。 2016年双十一，RocketMQ承载了万亿级消息的流转，跨越了一个新的里程碑。11月28日，阿里巴巴
  向 Apache 软件基金会捐赠 RocketMQ，成为 Apache 孵化项目。
• 2017 年 9 月25日，Apache 宣布 RocketMQ孵化成为 Apache 顶级项目（TLP ），成为国内首个互联
  网中间件在 Apache 上的顶级项目。

二、特点

• 是一个队列模型的消息中间件，具有高性能、高可靠、高实·时、分布式等特点
• Producer、Consumer、队列都可以分布式
• Producer 向一些队列轮流发送消息，队列集合称为 Topic，Consumer 如果做广播消费，则一个 Consumer 实例消费这个 Topic 对应的所有队列，如果做集群消费，则多个 Consumer 实例平均消费这个 Topic 对应的队列集合
• 能够保证严格的消息顺序
• 支持拉（pull）和推（push）两种消息模式
• 高效的订阅者水平扩展能力
• 实时的消息订阅机制
• 亿级消息堆积能力
• 支持多种消息协议，如 JMS、OpenMessaging 等
• 较少的依赖

三、作用

1、异步

​ 异步处理，比如A服务做了什么事情，异步发送一个消息给其他B服务。

2、解耦

​ 解耦，降低服务模块直接通信的耦合性。

3、削峰

​ 削峰，有些服务请求量很高，服务处理不过来，那么请求先放到消息队列里面，再进行处理。

四、核心概念

• Producer
  消息生产者，将业务系统生成的消息发送给消息代理（Broker），RocketMQ 提供了多种发送消息的模式：同步（synchronous）、异步（asynchronous）和单向（one-way）。
• Producer Group
  消息生产者组，具有相同角色的消息生产者组合在一起，相同角色可以理解为生产同一类消息。
• Consumer
  消息消费者，从消息代理（Broker）获取消息并将其提供给应用程序。又可以根据消息获取方式分为：
  (1) Pull Consumer
  积极主动地从消息代理（Broker）中拉取消息，一旦批量消息被拉出，用户应用便启动消息。
  (2) Push Consumer
  将拉动消息、消费进度和其它维护工作封装起来，留下一个回调接口给最终用户实现，这个接口在消息到达时会被执行。
• Consumer Group
  消息消费者组，同消息生产者组类似，将具有相同角色的消息消费者组合在一起，相同角色可以理解为消费同一类消息。
• Topic
  Topic 是消息的逻辑分类。
• Message
  Message 是发送的信息载体，Message 必须指定 Topic，可以类比信件地址。Message 有一个可选的 Tag 设置便于过滤消息，还可以添加额外的键值对。
• Message Queue
  Topic 会被分为一个或多个 Message Queue
• Tag
  Tag 是 Topic 的进一步细分，为用户提供额外的灵活性。同一业务不同目的的消息可以拥有相同的 Topic 和不同的 Tag。
• Broker
  Broker 是 RocketMQ 系统主要组件，接收来自消息生产者的消息，存储这些消息并为消息消费者拉动这些消息做准备，也存储消息相关元数据。
• Name Server
  Name Server 为消息生产者和消费者提供路由信息。
• Message Model
  消息模型：集群（Clustering）和广播（Broadcasting）
• Message Order
  消息顺序：顺序（Orderly）和并发（Concurrently）

五、消息模型

​ RockerMQ 中的消息模型就是按照 主题模型 所实现的。你可能会好奇这个 主题 到底是怎么实现的呢？你上面也没有讲到呀！

​ 其实对于主题模型的实现来说每个消息中间件的底层设计都是不一样的，就比如 Kafka 中的 分区 ，RocketMQ 中的 队列 ，RabbitMQ 中的 Exchange 。我们可以理解为 主题模型/发布订阅模型 就是一个标准，那些中间件只不过照着这个标准去实现而已。

​ 所以，RocketMQ 中的 主题模型 到底是如何实现的呢？首先我画一张图，大家尝试着去理解一下。

​ 我们可以看到在整个图中有 Producer Group 、Topic 、Consumer Group 三个角色，我来分别介绍一下他们。

• Producer Group 生产者组： 代表某一类的生产者，比如我们有多个秒杀系统作为生产者，这多个合在一起就是一个 Producer Group 生产者组，它们一般生产相同的消息。

• Consumer Group 消费者组： 代表某一类的消费者，比如我们有多个短信系统作为消费者，这多个合在一起就是一个 Consumer Group 消费者组，它们一般消费相同的消息。

• Topic 主题： 代表一类消息，比如订单消息，物流消息等等。

  ​ 你可以看到图中生产者组中的生产者会向主题发送消息，而 主题中存在多个队列，生产者每次生产消息之后是指定主题中的某个队列发送消息的。

  ​ 每个主题中都有多个队列(这里还不涉及到 Broker)，集群消费模式下，一个消费者集群多台机器共同消费一个 topic 的多个队列，一个队列只会被一个消费者消费。如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。就像上图中 Consumer1 和 Consumer2 分别对应着两个队列，而 Consuer3 是没有队列对应的，所以一般来讲要控制 消费者组中的消费者个数和主题中队列个数相同 。

  ​ 当然也可以消费者个数小于队列个数，只不过不太建议。如下图。

​ 每个消费组在每个队列上维护一个消费位置 ，为什么呢？

​ 因为我们刚刚画的仅仅是一个消费者组，我们知道在发布订阅模式中一般会涉及到多个消费者组，而每个消费者组在每个队列中的消费位置都是不同的。如果此时有多个消费者组，那么消息被一个消费者组消费完之后是不会删除的(因为其它消费者组也需要呀)，它仅仅是为每个消费者组维护一个 消费位移(offset) ，每次消费者组消费完会返回一个成功的响应，然后队列再把维护的消费位移加一，这样就不会出现刚刚消费过的消息再一次被消费了。

​ 可能你还有一个问题，为什么一个主题中需要维护多个队列 ？

​ 答案是 提高并发能力 。的确，每个主题中只存在一个队列也是可行的。你想一下，如果每个主题中只存在一个队列，这个队列中也维护着每个消费者组的消费位置，这样也可以做到 发布订阅模式 。如下图。

​ 但是，这样我生产者是不是只能向一个队列发送消息？又因为需要维护消费位置所以一个队列只能对应一个消费者组中的消费者，这样是不是其他的 Consumer 就没有用武之地了？从这两个角度来讲，并发度一下子就小了很多。

​ 所以总结来说，RocketMQ 通过使用在一个 Topic 中配置多个队列并且每个队列维护每个消费者组的消费位置 实现了 主题模式/发布订阅模式 。

六、基础架构

1、RocketMQ 架构图中展示了四个集群：

• NameServer 集群
  提供轻量级的服务发现及路由，每个 NameServer 记录完整的路由信息，提供相应的读写服务，支持快速存储扩展。有些其它开源中间件使用 ZooKeeper 实现服务发现及路由功能，如 Apache Kafka。
  NameServer是一个功能齐全的服务器，主要包含两个功能：
  (1) Broker 管理，接收来自 Broker 集群的注册请求，提供心跳机制检测 Broker 是否存活
  (2) 路由管理，每个 NameServer 持有全部有关 Broker 集群和客户端请求队列的路由信息

• Broker 集群
  通过提供轻量级的 Topic 和Queue 机制处理消息存储。同时支持推（Push）和拉（Pull）两种模型，包含容错机制。提供强大的峰值填充和以原始时间顺序累积数千亿条消息的能力。此外还提供灾难恢复，丰富的指标统计数据和警报机制，这些都是传统的消息系统缺乏的。
  Broker 有几个重要的子模块：
  (1) 远程处理模块，Broker 入口，处理来自客户端的请求
  (2) 客户端管理，管理客户端（包括消息生产者和消费者），维护消费者的主题订阅
  (3) 存储服务，提供在物理硬盘上存储和查询消息的简单 API
  (4) HA 服务，提供主从 Broker 间数据同步
  (5) 索引服务，通过指定键为消息建立索引并提供快速消息查询

• Producer 集群
  消息生产者支持分布式部署，分布式生产者通过多种负载均衡模式向 Broker 集群发送消息。

• Consumer 集群
  消息消费者也支持 Push 和 Pull 模型的分布式部署，还支持集群消费和消息广播。提供了实时的消息订阅机制，可以满足大多数消费者的需求。

2、有关架构图中集群间交互方式的说明：
(1) Broker Master 和 Broker Slave 是主从结构，会执行数据同步 Data Sync
(2) 每个 Broker 与 NameServer 集群中所有节点建立长连接，定时注册 Topic 信息到所有 NameServer
(3) Producer 与 NameServer 集群中的其中一个节点（随机）建立长连接，定期从 NameServer 获取 Topic 路由信息，并与提供 Topic 服务的 Broker Master 建立长连接，定时向 Broker 发送心跳
(4) Producer 只能将消息发送到 Broker Master，但是 Consumer 同时和提供 Topic 服务的 Master 和 Slave 建立长连接，既可以从 Master 订阅消息，也可以从 Slave 订阅消息。

七、如何解决消息队列带来的问题

1、顺序消费

​ 其实很简单，我们需要处理的仅仅是将同一语义下的消息放入同一个队列(比如这里是同一个订单)，那我们就可以使用 Hash取模法 来保证同一个订单在同一个队列中就行了。

2、重复消费

​ 解决重复消费问题，使用幂等实现。而实现幂等的方式有：redis的key、value；数据库插入法，基于数据库的唯一键来保证重复数据不会被插入多条。

3、分布式事务

​ 如何解释分布式事务呢？事务大家都知道吧？要么都执行要么都不执行 。在同一个系统中我们可以轻松地实现事务，但是在分布式架构中，我们有很多服务是部署在不同系统之间的，而不同服务之间又需要进行调用。比如此时我下订单然后增加积分，如果保证不了分布式事务的话，就会出现A系统下了订单，但是B系统增加积分失败或者A系统没有下订单，B系统却增加了积分。前者对用户不友好，后者对运营商不利，这是我们都不愿意见到的。

​ 那么，如何去解决这个问题呢？

​ 如今比较常见的分布式事务实现有 2PC、TCC 和事务消息(half 半消息机制)。每一种实现都有其特定的使用场景，但是也有各自的问题，都不是完美的解决方案。

在 RocketMQ 中使用的是 事务消息加上事务反查机制 来解决分布式事务问题的。我画了张图，大家可以对照着图进行理解。

在第一步发送的 half 消息 ，它的意思是 在事务提交之前，对于消费者来说，这个消息是不可见的 。

那么，如何做到写入消息但是对用户不可见呢？RocketMQ事务消息的做法是：如果消息是half消息，将备份原消息的主题与消息消费队列，然后 改变主题 为RMQ_SYS_TRANS_HALF_TOPIC。由于消费组未订阅该主题，故消费端无法消费half类型的消息，然后RocketMQ会开启一个定时任务，从Topic为RMQ_SYS_TRANS_HALF_TOPIC中拉取消息进行消费，根据生产者组获取一个服务提供者发送回查事务状态请求，根据事务状态来决定是提交或回滚消息。

​ 你可以试想一下，如果没有从第5步开始的 事务反查机制 ，如果出现网路波动第4步没有发送成功，这样就会产生 MQ 不知道是不是需要给消费者消费的问题，他就像一个无头苍蝇一样。在 RocketMQ 中就是使用的上述的事务反查来解决的，而在 Kafka 中通常是直接抛出一个异常让用户来自行解决。

​ 你还需要注意的是，在 MQ Server 指向系统B的操作已经和系统A不相关了，也就是说在消息队列中的分布式事务是——本地事务和存储消息到消息队列才是同一个事务。这样也就产生了事务的最终一致性，因为整个过程是异步的，每个系统只要保证它自己那一部分的事务就行了。

4、消息堆积

​ 在上面我们提到了消息队列一个很重要的功能——削峰 。那么如果这个峰值太大了导致消息堆积在队列中怎么办呢？

​ 其实这个问题可以将它广义化，因为产生消息堆积的根源其实就只有两个——生产者生产太快或者消费者消费太慢。

​ 我们可以从多个角度去思考解决这个问题，当流量到峰值的时候是因为生产者生产太快，我们可以使用一些 限流降级 的方法，当然你也可以增加多个消费者实例去水平扩展增加消费能力来匹配生产的激增。如果消费者消费过慢的话，我们可以先检查 是否是消费者出现了大量的消费错误 ，或者打印一下日志查看是否是哪一个线程卡死，出现了锁资源不释放等等的问题。

​ 当然，最快速解决消息堆积问题的方法还是增加消费者实例，不过 同时你还需要增加每个主题的队列数量 。

​ 别忘了在 RocketMQ 中，一个队列只会被一个消费者消费 ，如果你仅仅是增加消费者实例就会出现我一开始给你画架构图的那种情况。

5、回溯消费

​ 回溯消费是指 Consumer 已经消费成功的消息，由于业务上需求需要重新消费，在RocketMQ 中， Broker 在向Consumer 投递成功消息后，消息仍然需要保留 。并且重新消费一般是按照时间维度，例如由于 Consumer 系统故障，恢复后需要重新消费1小时前的数据，那么 Broker 要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒。

八、刷盘机制

上面我讲了那么多的 RocketMQ 的架构和设计原理，你有没有好奇

在 Topic 中的 队列是以什么样的形式存在的？

队列中的消息又是如何进行存储持久化的呢？

我在上文中提到的 同步刷盘 和 异步刷盘 又是什么呢？它们会给持久化带来什么样的影响呢？

下面我将给你们一一解释。

1、同步刷盘和异步刷盘

​ 如上图所示，在同步刷盘中需要等待一个刷盘成功的 ACK ，同步刷盘对 MQ 消息可靠性来说是一种不错的保障，但是 性能上会有较大影响 ，一般地适用于金融等特定业务场景。

​ 而异步刷盘往往是开启一个线程去异步地执行刷盘操作。消息刷盘采用后台异步线程提交的方式进行， 降低了读写延迟 ，提高了 MQ 的性能和吞吐量，一般适用于如发验证码等对于消息保证要求不太高的业务场景。

​ 一般地，异步刷盘只有在 Broker 意外宕机的时候会丢失部分数据，你可以设置 Broker 的参数 FlushDiskType 来调整你的刷盘策略(ASYNC_FLUSH 或者 SYNC_FLUSH)。

2、同步复制和异步复制

​ 上面的同步刷盘和异步刷盘是在单个结点层面的，而同步复制和异步复制主要是指的 Borker 主从模式下，主节点返回消息给客户端的时候是否需要同步从节点。

• 同步复制： 也叫 “同步双写”，也就是说，只有消息同步双写到主从结点上时才返回写入成功 。

• 异步复制： 消息写入主节点之后就直接返回写入成功 。

  ​ 然而，很多事情是没有完美的方案的，就比如我们进行消息写入的节点越多就更能保证消息的可靠性，但是随之的性能也会下降，所以需要程序员根据特定业务场景去选择适应的主从复制方案。

  那么，异步复制会不会也像异步刷盘那样影响消息的可靠性呢？

  答案是不会的，因为两者就是不同的概念，对于消息可靠性是通过不同的刷盘策略保证的，而像异步同步复制策略仅仅是影响到了 可用性 。为什么呢？其主要原因是 RocketMQ 是不支持自动主从切换的，当主节点挂掉之后，生产者就不能再给这个主节点生产消息了。

  比如这个时候采用异步复制的方式，在主节点还未发送完需要同步的消息的时候主节点挂掉了，这个时候从节点就少了一部分消息。但是此时生产者无法再给主节点生产消息了，消费者可以自动切换到从节点进行消费(仅仅是消费)，所以在主节点挂掉的时间只会产生主从结点短暂的消息不一致的情况，降低了可用性，而当主节点重启之后，从节点那部分未来得及复制的消息还会继续复制。

  在单主从架构中，如果一个主节点挂掉了，那么也就意味着整个系统不能再生产了。那么这个可用性的问题能否解决呢？一个主从不行那就多个主从的呗，别忘了在我们最初的架构图中，每个 Topic 是分布在不同 Broker 中的。

​ 但是这种复制方式同样也会带来一个问题，那就是无法保证 严格顺序 。在上文中我们提到了如何保证的消息顺序性是通过将一个语义的消息发送在同一个队列中，使用 Topic 下的队列来保证顺序性的。如果此时我们主节点A负责的是订单A的一系列语义消息，然后它挂了，这样其他节点是无法代替主节点A的，如果我们任意节点都可以存入任何消息，那就没有顺序性可言了。

​ 而在 RocketMQ 中采用了 Dledger 解决这个问题。他要求在写入消息的时候，要求至少消息复制到半数以上的节点之后，才给客⼾端返回写⼊成功，并且它是⽀持通过选举来动态切换主节点的。这里我就不展开说明了，读者可以自己去了解。

也不是说 Dledger 是个完美的方案，至少在 Dledger 选举过程中是无法提供服务的，而且他必须要使用三个节点或以上，如果多数节点同时挂掉他也是无法保证可用性的，而且要求消息复制半数以上节点的效率和直接异步复制还是有一定的差距的。

3、存储机制

说明：

• 消息主体以及元数据都存储在CommitLog当中
• Consume Queue是一个逻辑队列，存储了这个Queue在CommiLog中的 起始offset，log大小和MessageTag的hashCode。
• 每次读取消息队列先读取consumer Queue,然后再通过consumerQueue去commitLog中拿到消息主体。

关于RocketMQ 的通俗解释

https://juejin.cn/post/6844904018322391054

参考：

https://www.jianshu.com/p/2ae8e81718d3

https://blog.csdn.net/weixin_44678356/article/details/119571707

https://blog.csdn.net/baidu_30994081/article/details/79446046

umer Queue,然后再通过consumerQueue去commitLog中拿到消息主体。

关于RocketMQ 的通俗解释

https://juejin.cn/post/6844904018322391054

参考：

https://www.jianshu.com/p/2ae8e81718d3

https://blog.csdn.net/weixin_44678356/article/details/119571707

https://blog.csdn.net/baidu_30994081/article/details/79446046