RocketMQ5实践

RocketMQ 是一项阿里巴巴集团开发的，以其高效、可靠和灵活性而闻名的技术框架，它支持广泛的消息传递模式和协议，可在大规模分布式系统中实现高并发、高可用、低延迟的消息传递。RocketMQ 提供了灵活的部署方式和多种编程语言的客户端 SDK，方便开发人员快速构建分布式应用程序。

RocketMQ 的作用主要包括：

1.解耦消息生产和消费：通过将生产者和消费者之间的通信交由消息中间件处理，可以有效地解耦分布式系统中的各个组件。这使得系统更加灵活、可扩展和易于维护。

2.提高系统可靠性和性能：RocketMQ 提供了消息持久化、容错机制和数据冗余等功能，确保消息在传递过程中不会丢失，并能够快速恢复故障。同时，其高效的消息传递机制有助于提高系统的性能和吞吐量。

3.实现异步通信和解决大流量问题：RocketMQ 支持异步消息传递和负载均衡等特性，可以帮助应对大量的请求和高并发场景，减少系统响应时间和延迟。

4.支持多种消息模式和协议：RocketMQ 支持各种消息传递模式，包括点对点、发布订阅和请求响应等。同时，它还支持多种消息协议，如 AMQP、JMS 等，可以方便地与其他系统进行集成。

消息中间件(MQ)的定义

一般认为，消息中间件属于分布式系统中一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成。

系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验

使用消息中间件，系统的耦合性就会降低。比如物流系统发生故障，需要几分钟才能来修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作正常完成。当物流系统恢复后，继续处理存放在消息队列中的订单消息即可，终端系统感知不到物流系统发生过几分钟故障。

流量削峰

应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮。有了消息队列可以将大量请求缓存起来，分散到很长一段时间处理，这样可以大大提到系统的稳定性和用户体验。

RocketMQ启动安装

RockeMQ的基本概念

消息的发送与消费模型

主题(Topic)

标识RocketMQ中一类消息的逻辑名字，消息的逻辑管理单位。无论消息生产还是消费，都需要指定Topic。主题主要用于区分消息的种类：一个生产者可以发送消息给一个或者多个Topic，消息的消费者也可以订阅一个或者多个Topic消息。

消息队列 ( Message Queue )

简称Queue或Q。消息物理管理单位。一个Topic将有若干个Q。

无论生产者还是消费者，实际的生产和消费都是针对Q级别。例如Producer发送消息的时候，会预先选择（默认轮询）好该Topic下面的某一条Q发送；Consumer消费的时候也会负载均衡地分配若干个Q，只拉取对应Q的消息。

生产者(Producer)

生产者 ：也称为消息发布者，负责发送消息至RocketMQ。

消费者(Consumer)

消费者 ：也称为消息订阅者，负责从RocketMQ接收并消费消息。

消费者分组(ConsumerGroup)

标识一类Consumer的集合名称，这类Consumer通常消费一类消息（也称为Consumer Group），且消费逻辑一致。同一个Consumer Group下的各个实例将共同消费topic的消息，起到负载均衡的作用。

订阅关系（Subscription）

RocketMQ中的消费者订阅关系（Subscription）是指消费者与主题（Topic）之间的订阅关系。

消费者可以通过指定订阅规则来订阅某个主题的消息。

普通消息的发送与消费

三种消息发送方式

同步发送消息

同步发送是指消息发送方发出数据后，同步等待，直到收到接收方发回响应之后才发下一个请求。这种可靠性同步地发送方式使用的比较广泛，比如：重要的消息通知，短信通知。

异步发送消息

异步消息通常用在对响应时间敏感的业务场景，即发送端不能容忍长时间地等待Broker的响应。消息发送方在发送了一条消息后，不等接收方发回响应，接着进行第二条消息发送。发送方通过回调接口的方式接收服务器响应，并对响应结果进行处理。

单向发送消息

这种方式主要用在不特别关心发送结果的场景，例如日志发送。单向（Oneway）发送特点为发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。此方式发送消息的过程耗时非常短，一般在微秒级别

两种消息消费方式

集群消费（负载均衡模式）

消费者采用集群消费方式消费消息，一个分组(Group)下的多个消费者共同消费队列消息，每个消费者处理的消息不同。一个Consumer Group中的各个Consumer实例分摊去消费消息，即一条消息只会投递到一个Consumer Group下面的一个实例。例如某个Topic有3个队列，其中一个Consumer Group 有 3 个实例，那么每个实例只消费其中的1个队列。集群消费模式是消费者默认的消费方式。
集群消费提交的偏移量，持久化是存在broker上的。

广播消费

广播消费模式中消息将对一个Consumer Group下的各个Consumer实例都投递一遍。即使这些 Consumer属于同一个Consumer Group，消息也会被Consumer Group 中的每个Consumer都消费一次。实际上，是一个消费组下的每个消费者实例都获取到了topic下面的每个Message Queue去拉取消费。所以消息会投递到每个消费者实例。
广播消费提交的偏移量，持久化是存在客户端（消费者）的。

两种消费监听方式

消息并发监听

消费端如果发生消息失败，没有提交成功（或者直接抛出异常、或者返回null值），消息默认情况下会进入重试队列中。
注意重试队列的名字其实是跟消费群组有关，不是主题，因为一个主题可以有多个群组消费，所以要注意

消息顺序监听

MessageListenerOrderly：在同一时刻只允许一个线程消费一个队列的消息，并且保证在消费这个队列消息的顺序性。

玩顺序消息时。consume消费消息失败时，不能返回reconsume——later，这样会导致乱序，应该返回suspend_current_queue_a_moment,意思是先等一会（默认1s），一会儿再处理这批消息，而不是放到重试队列里。
该消费线程在消费消息时，会使用锁来保证消息的顺序性。当某个消息消费失败时，该消息所属的队列会进入暂停状态，直到该消息处理成功后才会继续消费下一条消息。

严格使用顺序消息注意事项

但是这里有一个误区，不要认为这么做就可以确保顺序消费，因为这个顺序保障只是确保队列级的。消息在不同的队列中依然是无序的。所以要做到顺序消费，就必须要创建只能有一个队列的主题。同时就算一个主题只有一个队列，你也要使用顺序消费监听，如果使用并发消费监听一样会有问题。

分区顺序消息

批量消息的发送与消费

过滤消息

Tag过滤

在大多数情况下，TAG是一个简单而有用的设计，其可以来选择您想要的消息。

消费者将接收包含TAGA或TAGB或TAGC的消息。但是限制是一个消息只能有一个标签，这对于复杂的场景可能不起作用。在这种情况下，可以使用SQL表达式筛选消息。SQL特性可以通过发送消息时的属性来进行计算。
延时消息**

概念介绍

延时消息： Producer 将消息发送到消息队列RocketMQ 服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到Consumer 进行消费，该消息即延时消息。

适用场景

消息生产和消费有时间窗口要求：比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。如支付未完成，则关闭订单。如已完成支付则忽略。

使用方式

Apache RocketMQ目前只支持固定精度的定时消息，因为如果要支持任意的时间精度，在Broker 层面，必须## 标题要做消息排序，如果再涉及到持久化，那么消息排序要不可避免的产生巨大性能开销。（阿里云RocketMQ提供了任意时刻的定时消息功能，Apache的RocketMQ并没有,阿里并没有开源）

发送延时消息时需要设定一个延时时间长度，消息将从当前发送时间点开始延迟固定时间之后才开始投递。

延迟消息是根据延迟队列的level来的，延迟队列默认是

msg.setDelayTimeLevel(3)代表延迟10秒

“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”

是这18个等级（秒（s）、分（m）、小时（h）），level为1，表示延迟1秒后消费，level为5表示延迟1分钟后消费，level为18表示延迟2个小时消费。生产消息跟普通的生产消息类似，只需要在消息上设置延迟队列的level即可。消费消息跟普通的消费消息一致。

同时RocketMQ5还支持任意时间的演示

分布式事务流程

1.事务消息
RocketMQ 的事务消息包含三种状态：

半消息状态（Half Message）：发送方向服务器发送了消息，但是该消息还没有被提交；
提交状态（Commit Message）：发送方已经提交了消息，并且该消息已经被消费者接收；
回滚状态（Rollback Message）：发送方撤销了消息，并且该消息不会被消费者接收。
在分布式事务中，半消息状态是非常重要的，它表示该消息的发送者已经开始了一个事务，但是这个事务还没有被提交。如果消息发送成功，但是在后续的事务执行过程中出现错误，可以回滚该事务，并将半消息转化为回滚状态。

2.两阶段提交
RocketMQ 分布式事务的实现基于两阶段提交协议，该协议用于分布式系统中的事务处理。

第一阶段（准备阶段）：

发送方向 RocketMQ 发送半消息；
RocketMQ 收到半消息之后，返回 Ack 给发送方；
发送方执行本地事务操作，并根据操作结果决定是提交消息（Commit Message）还是撤销消息（Rollback Message）；
发送方向 RocketMQ 发送 Commit 或 Rollback 状态。
第二阶段（提交阶段）：

消费方接收到 Commit 或 Rollback 状态，进行对应的操作；
如果消费方无法正常处理消息，RocketMQ 会自动回滚该消息；
如果消费方正常处理消息，RocketMQ 会将消息标记为已完成，以便后续查询。

当消费者没有成功消费消息，将会进行相应的补偿操作，向生产者发送一条消息，生产者接受到消息后，进行补偿。

转自马士兵教育