《企业级云原生白皮书项目实战》——第六章 云原生最佳实践——6.3 基于 RocketMQ 的基金数字化陪伴体系的架构实践——6.3.3 RocketMQ 事务消息的金融应用场景(1)： https://developer.aliyun.com/article/1227798?groupCode=supportservice

6.3.3.3 分布式事务方案对比

在博时基金的业务场景下，需要解决的问题是事务一致性与服务解耦度之间的矛盾，因此我们的目标是让主从事务解耦，保证核心逻辑稳定，同时不因为解耦而牺牲最终一致性。因此，当时做出了几种不同的解决方案:

第一种方案:最常见普通消息+异步对账，这个方案的问题是无法保证主事务的执行和入队同时成功，需要时效性低的对账补偿解决，一致性只是较高。

第二种方案:本地消息表，对比上一种做法，它由业务将写入消息表放到主事务中，把主事务和入队变成一个原子操作，然后业务读取入队记录，自己投递给从事务。它的缺点是主事务和 消息表在存储上是耦合的，没有解耦度。

第三种方案:引入 XA 事务，是个两阶段提交的协议，实现难度较大。而且面临两个问题:一是这是一种同步阻塞协议，有锁占用导致并发不会太高，另外就是XA事务过程中，在参与者投赞成票后，如果协调者发生故障，节点不清楚应该提交还是中止，只能等待协调者恢复。这时候可能会出现业务中断。

第四种方案:TCC，专门处理分布式事务的TCC，只侧重于一致性，无解耦度，也是不可行。

第五种方案:事务消息，它能同时兼顾解耦度和一致性，是最合适的模式。最终我们选择了RocketMQ的事务消息作为分布式事务的解决方案。

图：五种解决方案详情

6.3.3.4 RocketMQ 事务消息核心流程

基于RocketMQ的事务消息搭建事务中心，协调分布式事务的推进和回滚。以优惠购为例，核心流程如下:

第一阶段:Prepare 阶段，即业务系统将RocketMQ 的半事务消息发送到事务中心，事务中心不做发布，等待二次确认。这个阶段RocketMQ的半消息在消费者端是感知不到的。

第二阶段:业务系统执行主事务，即购买货币基金。

第三阶段:主事务成功后commit到事务中心，由事务中心投递消息到从事务。如果主事务失败，就投递rollback给事务中心。这里需要两阶段提交的原因是:普通的入队操作无论放在主事务之前还是之后都无法保证最终一致。如果先执行主事务，再入队，那么可能在入队前，业务会宕机，就没有机会再入队了。如果先入队再执行主事务，那么可能主事务没有执行成功，但是从事务执行成功了，业务逻辑就会发生错乱。

图：事务消息解决分布式事务

由于网络抖动等原因，可能导致事务消息的二次确认丢失。此时需要依赖某种机制恢复整个分布式事务的上下文，RocketMQ 提供的反查机制正是为解决分布式事务中的超时问题而设计的。 我们的事务中心的反查机制流程主要是，先检查事务中心的内部状态，再通过反查接口检查本地事务的执行结果，恢复事务上下文后，正常推进后续的流程。

图：事务消息可靠性保障

《企业级云原生白皮书项目实战》——第六章 云原生最佳实践——6.3 基于 RocketMQ 的基金数字化陪伴体系的架构实践——6.3.3 RocketMQ 事务消息的金融应用场景(3)： https://developer.aliyun.com/article/1227771?groupCode=supportservice