From e99016b832eb83f3687fed98f428dd52237d3eff Mon Sep 17 00:00:00 2001 From: 8ga Date: Thu, 20 Mar 2025 14:53:47 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=20MQ/RocketMQ.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- MQ/RocketMQ.md | 47 +++++++++++++++++++++++++++++++++++++---------- 1 file changed, 37 insertions(+), 10 deletions(-) diff --git a/MQ/RocketMQ.md b/MQ/RocketMQ.md index a72b611..db55009 100644 --- a/MQ/RocketMQ.md +++ b/MQ/RocketMQ.md @@ -9,18 +9,18 @@ # 普通消息的使用场景 -## 微服务解耦 +##### 微服务解耦 - + -## 异步执行事件 +##### 异步执行事件 -## 数据集成 +##### 数据集成 -## 普通消息的声明周期 +## 生命周期 @@ -42,7 +42,7 @@ - 必须设置在24小时范围内,超过范围不生效 - 若设置在当前时间之前,服务端将立即投递 -## 声明周期 +## 生命周期 @@ -57,14 +57,41 @@ -顺序消息的关系是通过 Message Group 识别的,生产者发送顺序消息时,需要为每条顺序消息设置 Message Group。相同 Message Group 的消息遵循 FIFO 原则。所以有以下两个限制需要关注: +##### 注事事项 -- 必须一个生产者一个 Message Group 才能保障顺序性,不同的生产者设置同一个 Message Group 是无法保证顺序性的 -- 串行发送,使用多线程并行发送的话,也无法保障顺序性 +顺序消息的关系是通过 Message Group 识别的,生产者发送顺序消息时,需要为每条顺序消息设置 Message Group,相同 Message Group 的消息遵循 FIFO 原则。 -## 存储逻辑 +- 必须由同一个生产者投递,且投递到同一个 Message Group 才能保障顺序性 +- 必须串行发送,多线程得保证顺序投递消息,建议用最简单的方式单线程串行发送 + +##### 存储逻辑 相同的消息组按照先后顺序存储到同一个队列,不同消息组的消息可以混在同一个队列,但是不一定连续。 +# 事务消息 + +分布式和微服务应用中,分布式事务是一个非常重要的组件,传统的XA事务方案资源锁定范围大、并发度低。基于普通消息很难保障一致性,因为普通消息没有协调提交、回滚的能力。而事务消息就是补充了:普通消息的二阶段提交、与本地事务绑定的能力,实现最终一致性。 + + + +- 生产者发送消息到服务端 +- 服务端将消息持久化,向生产者返回Ack,确认消息发送成功 +- 此时消息被标记为"暂不能投递",这种消息叫做**半事务消息** +- 生产者继续执行本地事务,然后向服务端发送事务结果:提交/回滚 +- 服务端收到事务结果后 + + 事务提交:把半事务消息让消费者可见,让消费者成功消费 + + 事务回滚:取消投递半事务消息 + + 生产者异常:如果生产者因为宕机或者重启造成不可用,或者服务端收到的事务结果是 Unknown 等异常情况 + + 事务悬挂:为了避免生产者异常造成事务悬挂,服务端将会对生产者主动发起回查,第一次检查默认间隔 60 秒,支持自定义配置,最多不能超过1个小时 + + 事务超时:最多4个小时后超时,超时将强制回滚 + + 事务回查:生产者收到服务端的回查,要检查本地事务的执行结果,服务端根据回查结果决定要不要发消息 + +## 生命周期 + + + +## 注意事项 + +事务消息只保证**本地主分支事务**和**下游消息发送事务**的一致性,不能保证消息消费结果和上游事务的一致性。所以下游服务要保证自己的分支事务正确处理,并做好消费重试机制,宕机、重启这种短暂的不可用,可以直接利用服务端的重试机制。在消息提交到下游消费端处理完成之前,下游分支和上游事务之间的状态可能会不一致。因此,**事务消息仅适合接受异步执行的事务场景**。 \ No newline at end of file