复习昨日内容

为什么要使用消息队列

消息队列是大规模分布式系统中非常常用的一项中间件技术，它的具体应用场景有：确保可靠性、服务解耦、消息异步、削峰填谷。

解耦
在分布式系统中，服务提供方可以作为生产者将服务响应打包为消息事件，发送到消息队列当中，服务需求方从消息队列中消费事件，这样可以完成服务上下游的解耦，避免服务调用链上的某一环出错而导致服务雪崩。

消息异步
系统中耗时的工作可以打包为消息事件并放到 MQ 当中，由消费者异步消费事件，发送到 MQ 之后可以快速响应用户请求。比较典型的消息异步例子是：用户新建订单后，将商品服务和库存服务的调用交由 MQ 异步处理。

削峰
削峰是 MQ 尤其是 RocketMQ 最典型的应用场景。通过 MQ，可以将瞬时的高流量转化为持续的中低等流量，从而保护系统不被瞬时高流量冲垮。具体来说，大量用户请求到达系统后，将用户请求打包为消息事件交由 MQ，并快速响应用户请求。MQ 中的消息按顺序排队，从而达到削峰的效果。

为什么选择 RocketMQ

RocketMQ 具有低延迟、高吞吐量、高可用性等特点，非常适用于并发量大、实时性要求高的场景。

RocketMQ 的优缺点？

优点

• 单机吞吐量：十万级；
• 可用性：非常高，基于分布式架构，方便拓展；
• 消息可靠性：经过参数优化配置，可以做到 0 丢失；
• RocketMQ 支持 10 亿级别的消息堆积，不会因为消息堆积导致性能下降；
• 阿里出品，经过双十一等多轮电商场景的考验，稳定性值得信赖。

缺点

• 基于 Java 开发，对其他客户端的支持性较差；
• 系统迁移需要大量代码。

谈谈你对 RocketMQ 的理解？

RocketMQ 是一款可靠性强，可用性高，适用于并发量高，吞吐量大场景的消息队列中间件，主要由 NameServer、Broker、Producer 和 Consumer 四部分组成。

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

对比 Kafka，RocketMQ 支持事务且实时性更好；对比 RabbitMQ，RocketMQ 胜在分布式拓展能力以及海量消息的处理能力。

消息队列有哪些类型？

消息队列可以分为队列模型和发布-订阅模型。

队列模型指的就是 Producer 将消息放在队列当中，由 Consumer 进行消费。一旦 Consumer Group 中有一个 Consumer 将消息消费了，那么这个消息就不存在了，消费者之间是竞争关系。队列模型较为简单，是最基本的 MQ 模型。

发布-订阅模型中进一步引入了发布者（Publiser）、订阅者（Subscriber）以及主题（Topic）这三个概念。发布者负责生产和发送消息，它不直接将消息发送给订阅者，而是发送给消息队列组件；订阅者会接收所订阅主题的所有消息；主题是消息的分类或通道，发布者将消息发送到特定主题，订阅者从特定的主题接收消息。

发布-订阅模型的工作原理可以概括为：订阅者向消息系统注册一个或多个感兴趣的主题，发布者将消息发送到特定主题，消息系统负责将消息传递给所有订阅了该主题的订阅者，每个订阅者独立接收消息，彼此之间互不影响，也就是说一份消息可以被多次消费。

RocketMQ 采用哪种消息队列模型？

RocketMQ 采用发布-订阅模型。

RocketMQ 的消息模型在逻辑上包含多个核心组件，它们的协同工作构成了完整的消息系统。具体来说：
1. 基础消息单元：由 Message 以及 Message 的 Tag 构成。

• Message：消息传输的最小单位；
• Tag：Message 的二级分类（可以不指定 Tag），比如可以将一条发送给 Trade Topic 的 Message 进一步细分为 Payment / Refund …

2. 消息组织单元

• Topic（主题）：消息的一级分类，是消息的逻辑通道。生产者在发送消息时，必须指定消息的 Topic。同时，Topic 也是消费者订阅的基本单位。
• Queue（队列）：Queue 是消息实际存放的物理存储分片，每个 Topic 默认包含 4 个 Queue。生产者向 Topic 写入消息时，消息会均匀分布到某个 Queue，即** Message 会通过某种调度策略落到单个 Queue 当中**。Queue 是实现并行消费和水平拓展的基础。

3. 消费相关组件

• Consumer Group（消费者组）：消费者组是一组行为相同的消费者的逻辑集合。消费者组的消费模式有两种，分别是集群模式和广播模式。不同消费者组独立消费进度。
• Producer Group（生产者组）：生产者组是一组行为相同的生产者。

4. 消费位置管理

• Offset（偏移量）：标识消费者在 Queue 当中的消费进度。

消息的消费模式了解吗？

消息消费模式有两种：集群模式和广播模式。

默认情况下，消费者组采用集群消费，也就是一个消费者组当中的消费者竞争的消费 Topic 下的一条消息，一旦一条消息被消费过了，就不能重复消费了。

广播消费模式指的是 Topic 下的每一份消息都会发送给消费者组当中的每一个消费者消费一次。

了解 RocketMQ 的基本架构吗？

RocketMQ 的基本架构分为四部分，分别是 NameServer、Broker、Consumer 和 Producer。四者都采用集群模式部署，方便在分布式系统中快速地拓展。

详细解释一下 RocketMQ 基本架构中四个构成部分的作用？

NameServer
NameServer 是无状态（这里的「无状态」指的是 NameServer 仅存储最基本的路由元信息，所有数据的状态都是临时的，不会被持久化，而是仅存储在内存当中）服务器，角色类似于 Kafka 中的 Zookeeper。它的特点如下：

• 每个 NameServer 节点相互独立，无信息交互；
• NameServer 几乎是无状态的，通过部署多个节点来标识自己是一个伪集群。Producer 在发送消息时，会预先从 NameServer 得知自己要发送给的 Topic 的 Queue 位于哪个 Broker 上。Consumer 也会定时从 NameServer 获取 Topic 的 Queue 所在的 Broker 信息。Broker 在启动时，会将自己注册到 NameServer 当中，并通过心跳机制确保存活，定时维护 Topic 信息到 NameServer。
• 「需要注意的是」：由于 NameServer 节点之间相互独立，因此 Broker 启动时以及心跳保活时，都需要将自己的状态发送给所有 NameServer 并行地进行注册。逻辑上来说，NameServer 集群当中的所有节点最终的状态是一致的。

Broker
Broker 扮演消息存储与中转的角色。具体来说，Broker 的职责如下：

• 消息存储：持久化消息数据；
• 消息路由：保存 Topic 与 Queue 的映射关系；
• 服务提供：响应 Producer 的写入请求与 Consumer 的拉取请求；
• 高可用保障：通过主从架构实现数据冗余。

在 Broker 当中，真正存储消息的是 CommitLog，而 ConsumeGroup 存储消息的逻辑队列索引，它标记的是消息在 CommitLog 中的位置，按 Topic 和 Queue 进行分组。

单个 Broker 与所有 NameServer 保持长连接，定时将 Topic 信息同步到 NameServer。

Producer
Producer 是 RocketMQ 中负责发送消息的客户端组件，它是消息的源头，将业务系统产生的消息发送到 Broker 服务器。具体来说，Producer 有三种消息发送的模式，分别是：

• 同步发送：等待 Broker 返回确认消息；
• 异步发送：通过回调函数处理发送消息的结果；
• 单项发送：不关心发送的结果。

Producer 会自动从 NameServer 获取 Topic 的路由信息，从而将 Message 发送到 Topic 所在的 Broker 服务器，因此 Producer 只需要知道 NameServer 的服务地址即可。

Consumer
Consumer 是 RocketMQ 中负责接收消息的客户端组件，它从 Broker 中根据 Topic 拉取消息交由业务线程处理，是消息队列的最终目的地。

Consumer 有两种主要的消费模式，分别是：

• 拉取（Pull）模式：主动从 Broker 拉取感兴趣 Topic 的消息；
• 推送（Push）模式：Broker 推送消息给消费者（底层仍然是消费者主动拉取）；

学习 RocketMQ Day2：进阶（一）

如何保证消息的可用性/可靠性/不丢失呢？

消息的可靠性保障可以从：生产者、中间存储、消费者三方面入手。

生产者
在生产阶段，通过请求确认机制，来确保消息成功被存储：

• 同步发送时：注意处理响应结果与异常。消息成功发送才算成功，如果响应失败，则需要重试机制确保消息重新发送；
• 异步发送时：需要在回调函数中处理发送失败的情况，同样通过重试机制来确保消息重新发送；
• 如果发生响应超时，可以通过查询日志的 API 来查看消息是否成功存储到 Broker，如果失败仍然需要重试。

中间存储
存储阶段，可以通过配置可靠性优先的 Broker 来避免因故障宕机而造成的消息丢失：

• 消息只要持久化到了 CommitLog，即使 Broker 宕机，未经消费的消息也不会丢失；
• Broker 的刷盘机制：同步刷盘与异步刷盘。显然同步刷盘更可靠。
• Broker 通过主从模式确保高可用；

消费者
在消费者保障消息可靠意味着需要消费者成功将消息消费。关键在于消费者在客户端确认消息成功消费的时机，不应该在消息刚刚收到就确认消费，而应该在业务执行完毕时才确认消费。这样可以确保业务执行失败时可以重新消费消息。

如何处理消息重复的问题呢？

RocketMQ 可以确保消息一定投递且不丢失，即有消息可靠性保障，但是 RocketMQ 不能确保消息不被重复消费。

避免重复消费的两个手段是确保在业务端做好幂等性处理，或是进行消息去重。

幂等性指的就是多次相同的操作不会对系统产生副作用，显然读操作一定具备幂等性，难点在于如何确保写操作具有幂等性，比如库存系统如果收到重复的扣减库存消息，如何避免库存被重复扣减？

一个可选的确保幂等性的方式是，通过 MySQL 记录一张表，比如对于电商系统，新建一个订单表并使用唯一的 ID 对订单进行标识，这个表应该具有一个订单状态，如果订单的状态是已支付，那么重复到来的消息就不应该再一次扣减库存了。当然也可以在 Redis 缓存中设置标志位来达到类似的效果。