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