RocketMQ消息类型!
RocketMQ消息类型!
月伴飞鱼延迟消息
RocketMQ支持18个等级,每个等级代表一个延迟时间。
1 | private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h"; |
原理解析:
Brocker启动时,根据不同等级开启定时器,即分别对每个延迟等级都开启一个定时器。
- RocketMQ是基于
java.util.Timer
的定时器。
事务消息
支持在分布式场景下保障消息生产和本地事务的最终一致性。
1、生产者将消息发送至
Broker
。2、
Broker
将消息持久化成功之后,向生产者返回ACK
确认消息已经发送成功,此时消息被标记为 暂不能投递。
- 这种状态下的消息即为半事务消息。
3、生产者开始执行本地事务逻辑。
4、生产者根据本地事务执行结果向服务端提交二次确认结果(
Commit
或是Rollback
),Broker
收到确认结果后处理逻辑如下:
二次确认结果为
Commit
:Broker
将半事务消息标记为可投递,并投递给消费者。二次确认结果为
Rollback
:Broker
将回滚事务,不会将半事务消息投递给消费者。5、在断网或者是生产者应用重启的特殊情况下:
若
Broker
未收到发送者提交的二次确认结果,或Broker
收到的二次确认结果为Unknown
未知状态。经过固定时间后,服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查:
生产者收到消息回查后,需要检查对应消息的本地事务执行的最终结果。
生产者根据检查到的本地事务的最终状态再次提交二次确认,服务端仍按照步骤4对半事务消息进行处理。
为什么要先发送Half Message
(半消息):
可以先确认
Broker
服务器是否正常,如果半消息都发送失败了,那说明Broker
挂了。
什么情况会回查:
执行本地事务的时候,由于突然网络等原因一直没有返回执行事务的结果(
Commit
或者Rollback
)导致最终返回UNKNOW
,就会回查。本地事务执行成功后,返回
Commit
进行消息二次确认的时候的服务挂了。
- 这个时候在
Broker
端,它还是个Half Message
(半消息),这也会回查。