【每日八股】学习 RocketMQ Day1：基础

学习 RocketMQ Day1：基础

今天开始用大概两到三天学习一遍 RocketMQ 的知识，主要参考资料为：https://javabetter.cn/sidebar/sanfene/rocketmq.html。今天首先从基础部分开始。

为什么要使用消息队列？

消息队列是一种非常重要的中间件技术，广泛应用于分布式系统当中，以提高系统的可靠性、解耦能力和异步通信效率。

解耦

在分布式系统中，引入消息队列之后，服务提供方作为生产者将响应打包成消息事件放入消息队列当中，由服务需求方作为消费者从消息队列中拉取事件进行消费，这样就完成了服务之间的解耦。以某个分布式微服务系统为例，比如电商系统，当用户新建一个订单之后，订单服务需要跨服务调用库存服务扣减库存，这个时候就可以通过消息队列这个中间件来完成非常多的功能，例如：订单服务将库存扣减消息打包为一个定时消息事件放入消息队列当中，如果订单超时未支付，库存扣减回滚，否则库存服务实例按时消费消息并扣减库存。再比如：一个确保缓存与数据库一致性的手段是基于 binlog 确保最终一致性，该技术需要 Canal 和 MQ 协同工作，首先 Canal 伪装成从库从主库拉取 binlog，将其打包为消息事件放入 MQ，事件的众多订阅方直接从 MQ 中拉取消息进行消费即可，通过这种方式，从库作为消费者拉取到事件之后即可完成 binlog 同步。

异步

系统中耗时的工作可以放入 MQ 进行异步处理，从而快速地响应用户请求。比如用户下单之后，订单微服务直接返回给用户下单成功的通知，然后将订单信息放入消息队列，再由商品服务、库存服务等协同处理订单信息。

削峰

削峰填谷是 MQ 常见的应用场景，用于应对系统高并发请求的瞬时流量高峰。通过 MQ，可以将瞬时的高流量转化为持续的中低等流量，从而保护系统不会因为瞬时的高流量冲垮。

具体来说，用户到达系统时，系统的生产者直接将用户请求打包为消息事件放入 MQ，然后快速响应给用户结果。大量的消息事件按顺序排队，这样就可以达到削峰的效果，降低后端服务的压力。

为什么选择 RocketMQ？

以电商系统为例，这类系统主要面向 C 端用户，有一定的并发量，对性能的要求也较高，所以选择了低延迟、高吞吐量、可用性较好的 RocketMQ。

此外：

• RabbitMQ：常用于解耦和异步，很少用在大规模吞吐的场景中；
• Kafka：在大数据的实时计算和日志采集中大规模使用，是业界的标准。

RocketMQ 优缺点？

RocketMQ 优点：

• 单机吞吐量：10 万级；
• 可用性：非常高，基于分布式架构，可动态拓展；
• 消息可靠性：经过参数优化配置，消息可以做到 0 丢失；
• RocketMQ 支持 10 亿级别的消息堆积，且不会因为消息堆积导致性能下降；
• 天生适用于金融互联网领域，特别是针对可靠性要求高、吞吐量大的场景；
• RocketMQ 的稳定性值得信赖。

RocketMQ 缺点：

• 支持的客户端语言不多，但目前已经有 Golang 客户端支持；
• 没有在 MQ 核心中实现 JMS 接口，系统迁移需要修改大量代码。

谈谈你对 RocketMQ 的理解？

RocketMQ 是一款高性能、高可靠的消息队列中间件，采用发布-订阅模式，由 NameServer（路由发现）、Broker（消息存储）、Consumer（消费者）、Producer（生产者）四个主要部分构成。

RocketMQ 的优势在于低毫秒延迟、万亿级消息堆积能力、事务消息和顺序消息支持，并通过主从结构、数据分片和零拷贝技术保障高吞吐和可靠性，尤其适合电商系统以及金融交易等高可靠高吞吐的场景。

与 Kafka 相比，RocketMQ 强调事务和实时性，而对比 RabbitMQ 则胜在分布式拓展能力以及海量消息处理。

消息队列有哪些消息模型？

主要有两种消息模型：队列模型和发布-订阅模型。

队列模型
最初的 MQ 模型，对应“发 $\to$ 存 $\to$ 收”模型。生产者向队列发送消息，队列可以存储多个生产者的消息，一个队列可以有多个消费者，但消费者之间是竞争关系，也就是说每一条消息只能被一个消费者消费。

发布-订阅模型
针对需要将生产者的一条消息全量发布给多个消费者的场景，传统的队列模型显然不能满足该场景的需求，因此便引出了发布-订阅模型。

在发布-订阅模型中，消息发送方成为发布者（Publisher），接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）。发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅”主题。“订阅”是一个动作，每份订阅中，订阅者都可以接收到主题的所有消息。

队列模型与发布-订阅模型的核心区别在于消息是否可以被多次消费。

RocketMQ 的消息模型类型？

RocketMQ 采用标准的发布-订阅模型。

在 RocketMQ 中，一条具体的消息由 Message、Topic、Tag、Message Queue、Group、Offset 多部分组成。

Message

Message（消息）就是要传输的信息。

一条消息必须有一个主题（Topic，注意：在 RocketMQ 中，一条消息不可以有多个 Topic），主题指的就是消息要发布到的位置。

一条消息可以拥有可选的标签（Tag）和额外的键值对，它们可以用于设置一个业务 Key 并在 Broker 上查找消息以在开发过程中定位问题。

Topic

Topic（主题）可以被视为消息的归类，它是消息的第一级类型。比如对于电商系统，它的 Topic 可以分为：交易消息、物流消息等，一条消息必须有一个 Topic。

Topic 与生产者和消费者之间的关系非常松散，一个 Topic 可以有 0 个、1 个、多个生产者向其发送消息，一个生产者可以同时向多个不同的 Topic 发送消息，一个 Topic 可以被 0 个、1 个、多个消费者订阅。

Tag

Tag（标签）可以被视为子主题，是消息的第二级类型。例如，交易消息可以进一步分为：交易创建消息、交易取消消息等。一条消息可以没有 Tag。

Group

RocketMQ 中，订阅者的概念通过消费组（Consumer Group）体现。每个消费组消费 Topic 中一份完整的消息，不同消费组之间的消费进度互不干扰，即：一条消息被 Consumer Group 1 消费过，也会再给 Consumer Group 2 消费。

Consumer Group 中有多个 Consumer，同一个组内的 Consumer 是竞争关系，每个 Consumer 负责消费组内的一部分消息。默认情况下，如果一份消息被消费组中的一个消费者消费掉了，那么该组中的其他消费者不会再重复消费这条消息。

Message Queue

一个 Topic 下可以设置多个 Message Queue（消息队列），即 Topic 包括多个 Message Queue。如果一个 Consumer 需要获取 Topic 下的所有消息，就需要遍历所有 Message Queue。

Offset

在 Topic 被消费的过程中，由于消息需要被不同的组进行多次消费，因此被消费过的消息不会立即删除（因为一个 Consumer Group 消费完这条消息后，可能还有另一个 Consumer Group 也订阅了这个 Topic，但是还没有消费这条消息），这就需要 RocketMQ 为每个消费组定义一个消费位置（Consumer Offset），这个位置之前的消息都被消费过了，而之后的消息还没有。

消息的消费模式了解吗？

消费模式有两种：Clustering（集群消费）和 Broadcasting（广播消费）。

默认情况下进行集群消费，该模式下一个消费者组共同消费一个主题的多个队列，一个队列只会被消费者组当中的一个消费者所消费。如果消费者组中的某个消费者挂掉了，那么其他消费者会顶替挂掉的消费者继续消费消息。

广播消费则会将消息发给消费者组中的每一个消费者进行消费。

RocketMQ 的基本架构了解吗？

RocketMQ 由四部分组成：NameServer（路由发现）、Broker（消息存储）、Producer、Consumer。为了保证高可用，一般每一部分都进行集群部署。

介绍一下 RocketMQ 基本架构的四部分？

NameServer

NameServer 是一个无状态服务器，角色类似于 Kafka 中的 Zookeeper，但是比 Zookeeper 更轻量。

• 每个 NameServer 节点之间相互独立，彼此没有任何信息交互；
• NameServer 被设计为无状态的，通过部署多个节点来标识自己是一个伪集群，Producer 发消息前从 NameServer 获取 Topic 的路由信息，也就是应该将 Message 发往哪个存储着目标 Topic 的 Broker，Consumer 会定期从 NameServer 拉取 Topic 的路由信息。Broker 在启动时会向 NameServer 注册，并定时进行心跳检测，定时同步维护 Topic 到 NameServer。

NameServer 的主要功能：与 Broker 节点保持长连接，以复用连接进行 Broker 心跳保活以及即时得知新的 Topic 路由信息。

Broker

Broker 用于消息存储与消息中转，负责存储和转发。

• Broker 内部维护着一个个 Consumer Queue，用来存储消息的索引，真正存储消息的位置是 CommitLog（日志文件）；
• 单个 Broker 与所有 NameServer 保持长连接，定时将 Topic 信息同步到 NameServer。Broker 与 NameServer 的底层通信通过 Netty 实现。

Producer

消息的生产者，在业务端负责发送消息。

• Producer 由用户进行分布式部署，消息由 Producer 通过负载均衡模式发送到 Broker 集群，发送低延时，支持快速失败；

RocketMQ 提供了三种发送消息的方式，分别是同步、异步和单向：

• 同步：同步发送指发送方发送消息后等待接收方响应成功接收后才发送下一条消息，用于重要通知；
• 异步：发送方发送消息后不等待接收方恢复，接着发送之后的数据包；
• 单向发送：发送方只负责发送消息，不等待接收方响应，适用于耗时非常短但对可靠性要求不高的场景，比如日志收集。

Consumer

消息的消费者，一般是后台系统负责异步消费。

• Consumer 同样由用户部署，支持 PUSH 和 PULL 两种消费模式，支持集群和广播消费，提供实时的消息订阅机制。
• Pull：拉取型消费者（Pull Consumer）主动从消息服务器拉取信息，只要批量拉取到信息，用户应用就会启动消费线程，因此 Pull 又称为主动消费；
• Push：推送型消费者（Push Consumer）封装了消息拉取、消费进度和其他内部维护工作，将消息到达时执行的回调接口交由用户程序实现。因此 Push 又称为被动消费类型，不同于 Pull 的是 Push 类型要注册一个消息监听器，当监听器触发后才开始消费消息。