随着业务的快速发展，各层业务之间调用关系越来越复杂，对系统的可用性以及扩展性要求也越来越高。消息队列作为分布式架构中的重要一环，提供了消息传递和消息排队的模型，被应用在系统解耦、异步处理、流量削峰 等多个场景，有着举足轻重的地位。

MessageQueue 基本概念

MQ 场景

不需要立即获得结果，又需要对并发量进行控制，生产者-消费者模型。

MQ 特点

应用解耦

• 多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败（非事务逻辑）
• 发布-订阅模式可以让上游修改不修改代码，减少上游服务发布频率。

异步处理

• 多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少总处理时间、也加快了上游服务响应。
• 相比服务自身线程池，减少任务管理逻辑，MQ有存储和消费ACK确认，使服务本身无状态。

流量削峰

• 避免瞬时流量过大导致应用系统挂掉的情况。
• 且不同于限流降级的立即失败策略，MQ把请求“积蓄”了，消费者后续能处理到每个请求。
• 长远时间段内，需要生产量≤消费量，堆积是不正常的

MQ 模式

点对点模式

生产者 - MQ - 消费者

• 每个消息只有一个 Consumer，一旦被消费，消息就不再在消息队列中
• 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息
• 接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息

Topic 模式，发布/订阅模式

发布者 - MQ - 订阅者

• 每个消息可以有多个订阅者
• 发布者和订阅者之间有时间上的依赖性。针对某个 Topic 的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息
• 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行

引入MQ带来的问题

• 系统可用性
  • MQ 不可用时降级方案
• 复杂性
  • 重复消费
  • 消息丢失
  • 非顺序消费
• 数据一致性
  • 分布式事务

RMQ 基础篇

基本概念

1. 消息模型（Message Model）

RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。

2. 消息生产者（Producer）

负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。

3. 消息消费者（Consumer）

负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。

4. 主题（Topic）

表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。

5. 代理服务器（Broker Server）

消息中转角色，负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。

6. 生产者组（Producer Group）

同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

7. 消费者组（Consumer Group）

同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

8. 集群消费（Clustering）

集群消费模式下，相同的 Consumer Group 的每个Consumer实例平均分摊消息。

• 每条消息只需要被处理一次，broken 只会把消息发送给消费集群中的一个消费者

• 在消息重投时，不能保证路由到一台机器上

• 消费状态由 broker 维护

9. 广播消费（Broadcasting）

广播消费模式下，相同 Consumer Group 的每个Consumer实例都接受全量的消息。

• 消费进度由 consumer 维护
• 保证每个消费者都消费一次消息
• 失败的消息不会重复投递

10. 普通顺序消息（Normal Ordered Message）

普通顺序消费模式下，消费者通过同一个消息队列（Topic 分区，称为 Message Queue） 收到的消息是有顺序的，不同消息队列收到消息则可能是无顺序的。

11. 严格顺序消息（Strictly Ordered Message）

严格顺序消息模式下，消费者收到的所有消息均是有顺序的

RMQ 原理篇

1. 推送式 & 拉取式 Consumer

• 推模式

推模式指的是消息从 Broker 推向 Consumer，即 Consumer 被动的接收消息，由 Broker 来主导消息的发送。

Good：消息实时性高， Broker 接受完消息之后可以立马推送给 Consumer。对于消费者使用来说更简单，等着，有消息就会推过来。

Bad：推送速率难以适应消费速率，推模式的目标就是以最快的速度推送消息，当生产者往 Broker 发送消息的速率大于消费者消费消息的速率时，随着时间的增长消费者那边可能就“爆仓”了，因为根本消费不过来。甚至有可能造成攻击一般的推送流量

• 拉模式

拉模式指的是 Consumer 主动向 Broker 请求拉取消息，即 Broker 被动的发送消息给 Consumer。

Good：拉模式主动权就在消费者身上了，消费者可以根据自身的情况来发起拉取消息的请求。假设当前消费者觉得自己消费不过来了，它可以根据一定的策略停止拉取，或者间隔拉取都行。

Bad：消息延迟，毕竟是消费者去拉取消息，但是消费者怎么知道消息到了呢？所以它只能不断地拉取，但是又不能很频繁地请求，太频繁了就变成消费者在攻击 Broker 了。因此需要降低请求的频率，比如隔个 2 秒请求一次，你看着消息就很有可能延迟 2 秒了。

RocketMQ 和 Kafka 都选择了拉模式，都是利用“长轮询”来实现拉模式

2. 事务消息

​ 注册系统和邮件通知系统之间通过消息队列进行异步处理。注册系统将注册信息写入注册系统之后，发送一条注册成功的消息到消息队列RocketMQ版，邮件通知系统订阅消息队列RocketMQ版的注册消息，做相应的业务处理，发送注册成功或者失败的邮件。