事务消息应用场景、实现原理

户登录、用户注册等服务，一个新用户注册时，向MQ服务器中的USER_REGISTER主题发送一条消息，主流程结束，与送积分，送优惠券等过程解耦。

• 优惠券(券系统)

提供发放优惠券、使用优惠券等与券相关的基础服务。

• 积分中心

提供积分相关的服务，例如积分赠送、积分消费、积分查询等基础服务。

• 送积分服务(消费者)

订阅MQ，按照规则决定是否需要赠送积分，如果需要则调用积分相关的基础接口，完成积分的发放。

• 送优惠券(消费者)

订阅MQ，按照规则决定是否需要赠送优惠券，如果需要则调用券系统相关的基础接口，完成优惠券的发放。

上面的架构设计非常优雅，但并不是无懈可击，读者们肯定会想到如果新用户注册成功，但消息发送到MQ失败，或者消息成功发送到MQ，但发送完MQ后系统出现异常导致用户注册失败又该如何呢?

上面的问题其实就是典型的分布式事务问题：即如何保证用户注册(数据库操作)与MQ消息发送这两个分布式操作的一致性。

RocketMQ事务消息闪亮登场。

2、事务消息实现原理

一言以蔽之：RocketMQ事务消息要解决的问题是消息发送与业务的一致性，其解决思路：二阶段提交与事务状态回查，其具体实现流程如下图所示：


 

设计理念：

• 应用程序开启一个数据库事务，进行数据库操作，并且在事务中发送一条PREPARE消息，PREPARE消息发送成功后通知应用程序记录本地事务状态，然后提交本地事务。
• RocketMQ在收到类型为PREPARE的消息时，首先备份消息的原主题与原消息消费队列，然后将消息存储在主题为RMQ_SYS_TRANS_HALF_TOPIC的消息队列中，故PREPARE的消息是不会被客户端消费的。
• Broker消息服务器开启一个定时任务处理RMQ_SYS_TRANS_HALF_TOPIC中的消息，会每隔指定时间向消息发送者发起事务状态查询请求 ,询问消息发送者客户端本地事务是否成功，然后根据回查状态决定是提交还是回滚，即对处于PREPARE状态进行提交或回滚操作。
• 发送者如果明确得知事务成功，则可以返回COMMIT，服务端会提交该条消息，具体操作是恢复原消息的主题与队列，重新发送到Broker，消费端感知后消费。
• 发送者如果无法明确得知事务状态，则返回UNOWN，此时服务端会等待一定时间后再次向发送者询问，默认询问15次。
• 发送者如果非常明确得知事务失败，则可以返回ROLLBACK。

在具体实践中，消息发送者在无法获取事务状态时不要武断的返回ROLLBACK，而是要返回UNOWN，让服务端定时重试回查，说明如下：

（编辑：我爱制作网_潮州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!