RocketMQ分布式消息系统

RocketMQ 是一款功能强大的分布式消息系统，广泛应用于多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、移动应用、手游、视频、物联网、车联网等。
RocketMQ 源码地址：https://github.com/apache/rocketmq
RocketMQ 官方网站：https://rocketmq.apache.org
什么场景下用 RocketMQ？

1. 异步解耦

最常见的一个场景是用户注册后，需要发送注册邮件和短信通知，以告知用户注册成功。传统的做法有以下两种：
串行方式
串行方式下的注册流程如下图所示。

数据流动如下所述：

1. 您在注册页面填写账号和密码并提交注册信息，这些注册信息首先会被写入注册系统。
2. 注册信息写入注册系统成功后，再发送请求至邮件通知系统。邮件通知系统收到请求后向用户发送邮件通知。
3. 邮件通知系统接收注册系统请求后再向下游的短信通知系统发送请求。短信通知系统收到请求后向用户发送短信通知。
   以上三个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。
   假设每个任务耗时分别为50ms，则用户需要在注册页面等待总共150ms才能登录。
   并行方式
   并行方式下的注册流程如下图所示。

数据流动如下所述：

1. 用户在注册页面填写账号和密码并提交注册信息，这些注册信息首先会被写入注册系统。
2. 注册信息写入注册系统成功后，再同时发送请求至邮件和短信通知系统。邮件和短信通知系统收到请求后分别向用户发送邮件和短信通知。
   以上两个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。
   假设每个任务耗时分别为50ms，其中，邮件和短信通知并行完成，则用户需要在注册页面等待总共100ms才能登录。
   异步解耦
   对于用户来说，注册功能实际只需要注册系统存储用户的账户信息后，该用户便可以登录，后续的注册短信和邮件不是即时需要关注的步骤。
   对于注册系统而言，发送注册成功的短信和邮件通知并不一定要绑定在一起同步完成，所以实际当数据写入注册系统后，注册系统就可以把其他的操作放入对应的 RocketMQ 中然后马上返回用户结果，由 RocketMQ 异步地进行这些操作。
   

数据流动如下所述：

1. 用户在注册页面填写账号和密码并提交注册信息，这些注册信息首先会被写入注册系统。
2. 注册信息写入注册系统成功后，再发送消息至 RocketMQ。 RocketMQ 会马上返回响应给注册系统，注册完成。用户可立即登录。
3. 下游的邮件和短信通知系统订阅 RocketMQ 的此类注册请求消息，即可向用户发送邮件和短信通知，完成所有的注册流程。
   用户只需在注册页面等待注册数据写入注册系统和 RocketMQ 的时间，即等待55ms即可登录。

削峰填谷

流量削峰也是 RocketMQ 的常用场景，一般在秒杀或团队抢购活动中使用广泛。
在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在处理如此大量的访问流量后，下游的通知系统无法承载海量的调用量，甚至会导致系统崩溃等问题而发生漏通知的情况。为解决这些问题，可在应用和下游通知系统之间加入 RocketMQ。

秒杀处理流程如下所述：

1. 用户发起海量秒杀请求到秒杀业务处理系统。
2. 秒杀处理系统按照秒杀处理逻辑将满足秒杀条件的请求发送 RocketMQ。
3. 下游的通知系统订阅 RocketMQ 的秒杀相关消息，再将秒杀成功的消息发送到相应用户。
4. 用户收到秒杀成功的通知。

3. 顺序消息

顺序消息是 RocketMQ 提供的一种对消息发送和消费顺序有严格要求的消息。
对于一个指定的 Topic，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。
顺序消息分为分区顺序消息和全局顺序消息。
● 分区顺序消息：对于指定的一个 Topic，所有消息根据 Sharding Key 进行区块分区，同一个分区内的消息按照严格的先进先出（FIFO）原则进行发布和消费。同一分区内的消息保证顺序，不同分区之间的消息顺序不做要求。
○ 适用场景：适用于性能要求高，以 Sharding Key 作为分区字段，在同一个区块中严格地按照先进先出（FIFO）原则进行消息发布和消费的场景。
● 全局顺序消息：对于指定的一个Topic，所有消息按照严格的先入先出（FIFO）的顺序来发布和消费。
○ 适用场景：适用于性能要求不高，所有的消息严格按照 FIFO 原则来发布和消费的场景。
全局顺序消息实际上是一种特殊的分区顺序消息，即 Topic 中只有一个分区，因此全局顺序和分区顺序的实现原理相同。因为分区顺序消息有多个分区，所以分区顺序消息比全局顺序消息的并发度和性能更高。

假设有一个主题 TopicA，包含 4个队列（Queue0, Queue1, …, Queue3）。有一个消费者组 ConsumerGroupA，包含 4 个消费者实例（Consumer1, Consumer2）。在集群消费模式下，队列分配可能如下：
● Consumer1 负责消费 Queue0 和 Queue1
● Consumer2 负责消费 Queue2 和 Queue3

而在广播消费模式下，同一个消费者组内的每个消费者实例都会消费每条消息：
假设有一个主题 TopicA，包含 4个队列（Queue0, Queue1, …, Queue3）。有一个消费者组 ConsumerGroupA，包含 2 个消费者实例（Consumer1, Consumer2）。在广播消费模式下，队列分配如下：
● Consumer1 负责消费 Queue0，Queue1，Queue2 和 Queue3
● Consumer2 负责消费 Queue0，Queue1，Queue2 和 Queue3