消息队列 RocketMQ 事务消息全新升级-解决分布式事务一致性的最佳实践

特性功能

• 消息查询：消息队列 RocketMQ 版提供了三种消息查询的方式，分别是按 Message ID、Message Key 以及 Topic 查询。
• 查询消息轨迹：通过消息轨迹，能清晰定位消息从生产者发出，经由消息队列 RocketMQ 版服务端，投递给消息消费者的完整链路，方便定位排查问题。
• 集群消费和广播消费：当使用集群消费模式时，消息队列 RocketMQ 版认为任意一条消息只需要被消费者集群内的任意一个消费者处理即可；当使用广播消费模式时，消息队列 RocketMQ 版会将每条消息推送给消费者集群内所有注册过的消费者，保证消息至少被每台机器消费一次。
• 重置消费位点：根据时间或位点重置消费进度，允许用户进行消息回溯或者丢弃堆积消息。
• 死信队列：将无法正常消费的消息储存到特殊的死信队列供后续处理。
• 全球消息路由：用于全球不同地域之间的消息同步，保证地域之间的数据一致性。
• 资源报表：消息生产和消费数据的统计功能。通过该功能，您可查询在一段时间范围内发送至某 Topic 的消息总量或者 TPS（消息生产数据），也可查询在一个时间段内某 Topic 投递给某 Group ID 的消息总量或 TPS（消息消费数据）。
• 监控报警：您可使用消息队列 RocketMQ 版提供的监控报警功能，监控某 Group ID 订阅的某 Topic 的消息消费状态并接收报警短信，帮助您实时掌握消息消费状态，以便及时处理消费异常。

消息队列 RocketMQ 版的适用场景

为您介绍消息队列 RocketMQ 版的适用场景，以便您更好地判断如何在业务中使用消息队列 RocketMQ 版。

例如，针对一家互联网电商企业，其业务涉及广泛，如注册、订单、库存、物流等；同时，也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等。这些活动都对分布性系统中的各项微服务应用的处理性能带来很大的挑战。

消息队列 RocketMQ 版作为分布式系统中的重要组件，可用于应对这些挑战，例如解决应用的异步解耦。

下文先以用户注册为场景说明消息队列 RocketMQ 版如何实现以下功能：

• 异步解耦
• 分布式事务的数据一致性
• 消息的顺序收发

最后，再以电商的秒杀场景和价格同步场景分别说明消息队列 RocketMQ 版所实现的削峰填谷和大规模机器的缓存同步。

异步解耦

传统处理

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

• 串行方式
  串行方式下的注册流程如下图所示。

  数据流动如下所述：

  1. 用户在注册页面填写账号和密码并提交注册信息，这些注册信息首先会被写入注册系统成功。
  2. 注册信息写入注册系统成功后，再发送请求至邮件通知系统。邮件通知系统收到请求后向用户发送邮件通知。
  3. 邮件通知系统接收注册系统请求后再向下游的短信通知系统发送请求。短信通知系统收到请求后向用户发送短信通知。

  以上三个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。

  假设每个任务耗时分别为 50 ms，则用户需要在注册页面等待总共需要 150 ms 才能登录。

• 并行方式
  并行方式下的注册流程如下图所示。

  数据流动如下所述：

  1. 用户在注册页面填写账号和密码并提交注册信息，这些注册信息首先会被写入注册系统成功。
  2. 注册信息写入注册系统成功后，再同时发送请求至邮件和短信通知系统。邮件和短信通知系统收到请求后分别向用户发送邮件和短信通知。

  以上三个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。

  假设每个任务耗时分别为 50 ms，其中，邮件和短信通知并行完成，则用户需要在注册页面等待总共需要 100 ms 才能登录。

以下就注册场景中使用了消息队列 RocketMQ 版的效果进行说明。

异步解耦

对于用户来说，注册功能实际只需要注册系统存储用户的账户信息后，该用户便可以登录，后续的注册短信和邮件不是即时需要关注的步骤。

对于注册系统而言，发送注册成功的短信和邮件通知并不一定要绑定在一起同步完成，所以实际当数据写入注册系统后，注册系统就可以把其他的操作放入对应的消息队列 RocketMQ 版中然后马上返回用户结果，由消息队列 RocketMQ 版异步地进行这些操作。

数据流动如下所述：

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

用户只需在注册页面等待注册数据写入注册系统和消息队列 RocketMQ 版的时间，即等待 55 ms 即可登录。

异步解耦是消息队列 RocketMQ 版的主要特点，主要目的是减少请求响应时间和解耦。主要的适用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时，由于使用了消息队列 RocketMQ 版，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦和。

分布式事务的数据一致性

注册系统注册的流程中，用户入口在网页注册系统，通知系统在邮件系统，两个系统之间的数据需要保持最终一致。

普通消息处理

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

流程说明如下：

1. 注册系统发起注册。
2. 注册系统向消息队列 RocketMQ 版发送注册消息成功与否的消息。

   2.1 消息发送成功，进入 3。

   2.2 消息发送失败，导致邮件通知系统未收到消息队列 RocketMQ 版发送的注册成功与否的消息，而无法发送邮件，最终邮件通知系统和注册系统之间的状态数据不一致。

3. 邮件通知系统收到消息队列 RocketMQ 版的注册成功消息。
4. 邮件通知系统发送注册成功邮件给用户。

在这样的情况下，虽然实现了系统间的解藕，上游系统不需要关心下游系统的业务处理结果；但是数据一致性不好处理，如何保证邮件通知系统状态与注册系统状态的最终一致。

事务消息处理

此时，需要有利用消息队列 RocketMQ 版所提供的事务消息来实现系统间的状态数据一致性。

流程说明如下：

1. 注册系统向消息队列 RocketMQ 版发送半事务消息。

   1.1 半事务消息发送成功，进入 2。

   1.2 半事务消息发送失败，注册系统不进行注册，流程结束。（最终注册系统与邮件通知系统数据一致）

2. 注册系统开始注册。

   2.1 注册成功，进入 3.1。

   2.2 注册失败，进行 3.2。

3. 注册系统向消息队列 RocketMQ 版发送半消息状态。

   3.1 提交半事务消息，产生注册成功消息，进入 4。

   3.2 回滚半事务消息，未产生注册成功消息，流程结束。（最终注册系统与邮件通知系统数据一致）

4. 邮件通知系统接收消息队列 RocketMQ 版的注册成功消息。
5. 邮件通知系统发送注册成功邮件。（最终注册系统与邮件通知系统数据一致）

分布式事务消息的更多详细内容请参见事务消息。

消息的顺序收发

消息队列 RocketMQ 版顺序消息分为两种情况：

• 全局顺序：对于指定的一个 Topic，所有消息将按照严格的先入先出（FIFO）的顺序，进行顺序发布和顺序消费；
• 分区顺序：对于指定的一个 Topic，所有消息根据 Sharding Key 进行区块分区，同一个分区内的消息将按照严格的 FIFO 的顺序，进行顺发布和顺序消费，可以保证一个消息被一个进程消费。

  在注册场景中，可使用用户 ID 作为 Sharding Key 来进行分区，同一个分区下的新建、更新或删除注册信息的消息必须按照 FIFO 的顺序发布和消费。

顺序消息的详细内容请参见顺序消息。

削峰填谷

流量削峰也是消息队列 RocketMQ 版的常用场景，一般在秒杀或团队抢购活动中使用广泛。

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

秒杀处理流程如下所述：

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

大规模机器的缓存同步

双十一大促时，各个分会场会有玲琅满目的商品，每件商品的价格都会实时变化。使用缓存技术也无法满足对商品价格的访问需求，缓存服务器网卡满载。访问较多次商品价格查询影响会场页面的打开速度。

此时需要提供一种广播机制，一条消息本来只可以被集群的一台机器消费，如果使用消息队列 RocketMQ 版的广播消费模式，那么这条消息会被所有节点消费一次，相当于把价格信息同步到需要的每台机器上，取代缓存的作用。

广播消费的详细内容请参见集群消费和广播消费。