RocketMQ的事务投递

本文深入探讨RocketMQ的事务消息机制,包括HalfMessage的概念、消息回查过程及最终一致性的实现方式。通过下单流程实例,阐述如何确保分布式环境下消息的一致性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

RocketMQ的事务投递

这是阿里的分布式事务图:

  • 1、A服务先发送个Half Message给Brock端,消息中携带 B服务 即将要+100元的信息。
  • 2、当A服务知道Half Message发送成功后,那么开始第3步执行本地事务。
  • 3、执行本地事务(会有三种情况1、执行成功。2、执行失败。3、网络等原因导致没有响应)
  • 4.1)、如果本地事务成功,那么Product像Brock服务器发送Commit,这样B服务就可以消费该message。
  • 4.2)、如果本地事务失败,那么Product像Brock服务器发送Rollback,那么就会直接删除上面这条半消息。
  • 4.3)、如果因为网络等原因迟迟没有返回失败还是成功,那么会执行RocketMQ的回调接口,来进行事务的回查。

如果回查,那么一定要先查看当前事务的执行情况,再看是否需要重新执行本地事务。 本地事务执行成功后,返回Commit进行消息二次确认的时候的服务挂了,在重启服务那么这个时候在brock端,它还是个Half Message(半消息),这也会回查。如果不先查看当前事务的执行情况,而是直接执行事务,那么就相当于成功执行了两个本地事务。

基于MQ的事务处理特点

最终一致性

RocketMQ是一种最终一致性的分布式事务,就是说它保证的是消息最终一致性,而不是像2PC、3PC、TCC那样强一致分布式事务,至于为什么说它是最终一致性事务下面会详细说明。

Half Message(半消息)

是指暂不能被Consumer消费的消息。Producer 已经把消息成功发送到了 Broker 端,但此消息被标记为暂不能投递状态,处于该种状态下的消息称为半消息。需要 Producer

对消息的二次确认后,Consumer才能去消费它。

消息回查

由于网络闪段,生产者应用重启等原因。导致 Producer 端一直没有对 Half Message(半消息) 进行 二次确认。这是Brock服务器会定时扫描长期处于半消息的消息,会

主动询问 Producer端 该消息的最终状态(Commit或者Rollback),该消息即为 消息回查。

一个例子

以下单流程为例:

转载于:https://my.oschina.net/u/1000241/blog/3076800

### RocketMQ 事务消息的使用教程 RocketMQ事务消息主要用于解决分布式系统中的数据一致性问题。以下是关于其使用方法以及常见问题解决方案的具体说明。 #### 1. 生产端实现原理 在生产端,RocketMQ 实现了两阶段提交协议 (2PC),以确保本地事务和 MQ 消息的一致性。 - **第一阶段**: 发送半消息(Half Message)。Producer 向 Broker 发送一条标记为“未完成”的消息,并等待确认。 - **第二阶段**: 执行本地事务并通知 Broker 结果。如果本地事务成功,则向 Broker 提交 Commit 请求;如果失败,则发送 Rollback 请求[^1]。 代码示例如下: ```java public class TransactionProducer { private static final String NAMESRV_ADDR = "localhost:9876"; public static void main(String[] args) throws Exception { // 创建事务 Producer TransactionMQProducer producer = new TransactionMQProducer("transaction_producer_group"); producer.setNamesrvAddr(NAMESRV_ADDR); // 设置事务监听器 producer.setTransactionListener(new LocalTransactionExecuter()); producer.start(); try { // 构造消息 Message message = new Message("TopicTest", "TagA", ("Hello RocketMQ").getBytes(RemotingHelper.DEFAULT_CHARSET)); // 发送事务消息 SendResult sendResult = producer.sendMessageInTransaction(message, null); System.out.printf("%s%n", sendResult); } catch (Exception e) { e.printStackTrace(); } } // 定义事务执行逻辑 static class LocalTransactionExecuter implements TransactionListener { @Override public LocalTransactionState executeLocalTransaction(Message msg, Object arg) { // 执行本地事务逻辑 System.out.println("Executing local transaction..."); return LocalTransactionState.COMMIT_MESSAGE; // 返回 COMMIT 或 ROLLBACK } @Override public LocalTransactionState checkLocalTransaction(MessageExt msg) { // 回查本地事务状态 return LocalTransactionState.UNKNOW; } } } ``` #### 2. 消费端实现原理 消费端通过 Ack 机制来保障消息被正确处理。消费者接收到消息后会尝试多次重试,直到业务逻辑成功或者达到最大重试次数为止[^2]。 #### 3. 常见问题及解决方案 ##### (1)`System Busy` 错误 当 Producer 收到 `SYSTEM_BUSY` 错误时,表示当前 Broker 负载过高无法及时响应请求。可以通过调整参数缓解此问题,比如增加线程池大小或优化网络带宽配置[^3]。 ##### (2)事务超时 如果事务长时间处于未知状态(UNKNOWN),则可能是因为回查接口未能正常返回结果。建议检查以下几点: - 确认回查服务是否可用; - 缩短事务执行时间窗口; - 修改 `checkThreadPoolMinSize` 和 `checkThreadPoolMaxSize` 参数提升并发能力[^5]。 ##### (3)重复消费 由于网络抖动等原因可能导致同一消息被多次投递给 Consumer。为了避免这种情况,在设计业务逻辑时应考虑幂等性操作[^4]。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值