RocketMQ第6集消息的5大发送类型-CSDN博客

本文链接：https://blog.csdn.net/u011066470/article/details/141713001

一消息的分类

1.1 普通消息

1.1.1 同步消息

同步发送消息是指，Producer发出⼀条消息后，会在收到MQ返回的ACK之后才发下⼀条消息。该方式的消息可靠性最高，但消息发送效率太低。

代码层面：

1.1.2 异步发送消息

异步发送消息是指，Producer发出消息后无需等待MQ返回ACK，直接发送下⼀条消息。该方式的消息靠性可以得到保障，消息发送效率也可以。

代码层面

RocketMQ支持异步消息发送，这意味着生产者在发送消息后不会等待消息的发送结果，而是通过回调函数来处理发送结果(如记录表记录失败消息，进行重发机制)。这种方式适用于对实时性要求不高，但需要高并发处理的场景。

综述就是虽然RocketMQ的异步发送允许生产者在发送消息后不等待结果，但通过异步回调和内置的重试及流控机制，生产者最终可以确保消息的成功发送。

1.1.3 单向发送消息

单向发送消息是指，Producer仅负责发送消息，不等待、不处理MQ的ACK。该发送方式时MQ也不返回ACK。该方式的消息发送效率最高，但消息可靠性较差。

代码层面：

1.2 顺序消息

发送消息的顺序和消费者消费消息的顺序要保持一致。

例如，现在有TOPIC ORDER_STATUS (订单状态)，其下有4个Queue队列，该Topic中的不同消息用于描述当前订单的不同状态。假设订单有状态：未支付、已支付、发货中、发货成功、发货失败。

当发送和消费参与的Queue只有一个时，所保证的有序是整个Topic中消息的顺序，称为全局有序。

如果有多个Queue参与，其仅可保证在该Queue分区队列上的消息顺序，则称为分区有序。一般性的选择算法是，让选择key（或其hash值）与该Topic所包含的Queue的数量取模，其结果即为选择出的Queue的QueueId。

取模算法存在一个问题：不同选择key与Queue数量取模结果可能会是相同的，即不同选择key的消息可能会出现在相同的Queue，即同一个Consuemr可能会消费到不同选择key的消息。这个问题如何解决？一般性的作法是，从消息中获取到选择key，对其进行判断。若是当前Consumer需要消费的消息，则直接消费，否则，什么也不做。这种做法要求选择key要能够随着消息一起被 Consumer获取到。此时使用消息key作为选择key是比较好的做法。

1.3 延时消息*

典型的应用场景是，电商交易中超时未支付关闭订单的场景，12306平台订票超时未支付取消订票的场景。当消息写入到Broker后，在指定的时长后才可被消费处理的消息，称为延时消息。

1.4 mq的事务场景

1.4.1 mq的事务消息场景

1场景描述：

事务消息场景：工行用户A向建行用户B转账1万元。可以使用同步消息来处理该需求场景。

1.工行系统发送一个给B增款1万元的同步消息M给Broker

2.消息被Broker成功接收后，向工行系统发送成功ACK

3.工行系统收到成功ACK后从用户A中扣款1万元

4.建行系统从Broker中获取到消息M

5.建行系统消费消息M，即向用户B中增加1万元

2问题描述：

这其中是有问题的：若第3步中的扣款操作失败，但消息已经成功发送到了Broker。对于MQ来说，只要消息写入成功，那么这个消息就可以被消费。此时建行系统中用户B增加了1万元。出现了数据不一致问题

3解决方案：

方案就是为了确保消息投递与扣款操作能够在一个事务中，要成功都成功，有一个失败，则全部回滚。

1.4.2 XA事务解决方案

XA（Unix Transaction）是一种分布式事务解决方案，一种分布式事务处理模式，是基于XA协议的。XA模式中有三个重要组件：TC、TM、RM。

Transaction Coordinator，事务协调者。维护全局和分支事务的状态，驱动全局事务提交或回滚。 RocketMQ中Broker充当着TC。

Transaction Manager，事务管理器。定义全局事务的范围：开始全局事务、提交或回滚全局事务。它实际是全局事务的发起者。 RocketMQ中事务消息的Producer充当着TM。

Resource Manager，资源管理器。管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 RocketMQ中事务消息的Producer及Broker均是RM。

XA模式是一个典型的2PC，其执行原理如下：

1.TM向TC发起指令，开启一个全局事务。

2.根据业务要求，各个RM会逐个向TC注册分支事务，然后TC会逐个向RM发出预执行指令。

3.各个RM在接收到指令后会在进行本地事务预执行。

4.RM将预执行结果Report给TC。当然，这个结果可能是成功，也可能是失败。

5.TC在接收到各个RM的Report后会将汇总结果上报给TM，根据汇总结果TM会向TC发出确认指令。

若所有结果都是成功响应，则向TC发送Global Commit指令。

只要有结果是失败响应，则向TC发送Global Rollback指令。

6.TC在接收到指令后再次向RM发送确认指令。

注意：

1)事务消息不支持延时消息

2)对于事务消息要做好幂等性检查，因为事务消息可能不止一次被消费（因为存在回滚后再提交的情况）

3)事务消息方案并不是一个典型的XA模式。因为XA模式中的分支事务是异步的，而事务消息方案中的消息预提交与预扣款操作间是同步的。

1.4.3 基于RMQ事务消息实现最终一致性

1.半事务消息：发送方已经成功地将消息发送到了Broker，但是Broker未收到最终确认指令，此时该消息被标记成“暂不能投递”状态，即不能被消费者看到。处于该种状态下的消息即半事务消息

2.本地事务和事务消息一样，就是为了保证操作结果的一致性。

3.普通消息和订单事务无法保证一致的原因，本质上是由于普通消息无法像单机数据库事务一样，具备提交、回滚和统一协调的能力。

而基于 RocketMQ 实现的分布式事务消息功能，在普通消息基础上，支持二阶段的提交能力。将二阶段提交和本地事务绑定，实现全局提交结果的一致性。RocketMQ事务消息使用了2PC+事后补偿机制保证了最终一致性。

流程如下：

1.生产者将消息发送至broker；

2.broker将消息持久化成功后，向生产者返回Ack确认消息已经发送成功，此时消息被标记为【暂不能投递】，这种状态下的消息即为半事务消息。

3.生产者开始执行本地事务逻辑

4.生产者根据本地事务执行结果向服务端提交二次确认结果(commit或者是rollback)，broker收到确认结果后处理逻辑如下：

4.1 Commit: Broker 将半事务消息标记为可投递，并投递给消费者。

4.2 Rollback: Broker 将回滚事务，不会将半事务消息投递给消费者。

5.在断网或者生产者应用重启的特殊情况下，若broker未收到发送者提交的二次确认结果，或者broker收到二次确认结果为unkown，未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一实例发起消息回查。

生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。

生产者根据检查到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。

https://www.cnblogs.com/makemylife/p/18101509

1.4.4 半事务消息说明

1.生产端使用TransactionMQProducer发送业务消息到TopicA；底层ransactionMQProducer填充Message的properties属性键值TRAN_MSG=true，表示该消息为事务消息。

2.服务端Broker收到消息，存储时根据消息的properties的TRAN_MSG属性判断是否是事务消息。

如果为true（事务消息），把原Topic名字保存到Message的properties属性REAL_TOPIC中，并把本消息的Topic替换成RMQ_SYS_TRANS_HALF_TOPIC（半事务消息topic）然后保存并返回结果（到此完成发送半事务消息）。

总结：发送端使用TransactionMQProducer进行发送消息，broker端进行判断是否是事务消息，如果是事务消息，将消息放到RMQ_SYS_TRANS_HALF_TOPIC（半事务消息topic），然后保存并返回结果。

在rocket-broker依赖包中进行查看：

Broker收到消息，在做存储逻辑时根据消息的properties的TRAN_MSG属性判断是否是事务消息，如果true（事务消息），把原Topic名字保存到Message的properties属性REAL_TOPIC中，并把本消息的Topic替换成RMQ_SYS_TRANS_HALF_TOPIC，然后保存并返回结果（到此完成发送半事务消息）。