基于 RocketMQ 的基金数字化陪伴体系的架构实践

基于 RocketMQ 的基金数字化陪伴体系的架构实践

作者｜伍振河 本文以博时基金的金融场景为案例，阐述 RocketMQ 在提升客户陪伴效率和丰富金融场景化能力等方面的提升作用。

行业背景

RocketMQ 在陪伴体系中的应用

1、陪伴场景概述

2、RocketMQ 解耦异构系统

3、Topic 和 Tags 最佳实践

RocketMQ 事务消息的金融应用场景

1、金融场景概述

2、领域事件理论模型

3、布式事务方案对比

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

第一种方案：最常见普通消息+异步对账，这个方案的问题是无法保证主事务的执行和入队同时成功，需要时效性低的对账补偿解决，一致性只是较高。 第二种方案：本地消息表，对比上一种做法，它由业务将写入消息表放到主事务中，把主事务和入队变成一个原子操作，然后业务读取入队记录，自己投递给从事务。它的缺点是主事务和消息表在存储上是耦合的，没有解耦度。 第三种方案：引入 XA 事务，是个两阶段提交的协议，实现难度较大。而且面临两个问题：一是这是一种同步阻塞协议，有锁占用导致并发不会太高，另外就是 XA 事务过程中，在参与者投赞成票后，如果协调者发生故障，节点不清楚应该提交还是中止，只能等待协调者恢复。这时候可能会出现业务中断。 第四种方案：TCC，专门处理分布式事务的 TCC，只侧重于一致性，无解耦度，也是不可行。 第五种方案：事务消息，它能同时兼顾解耦度和一致性，是最合适的模式。

4、RocketMQ 事务消息核心流程

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

第一阶段：Prepare 阶段 ，即业务系统将 RocketMQ 的半事务消息发送到事务中心，事务中心不做发布，等待二次确认。这个阶段 RocketMQ 的半消息在消费者端是感知不到的。 第二阶段：业务系统执行主事务，即购买货币基金。 第三阶段：主事务成功后 commit 到事务中心，由事务中心投递消息到从事务。如果主事务失败，就投递 rollback 给事务中心。这里需要两阶段提交的原因是：普通的入队操作无论放在主事务之前还是之后都无法保证最终一致。如果先执行主事务，再入队，那么可能在入队前，业务会宕机，就没有机会再入队了。如果先入队再执行主事务，那么可能主事务没有执行成功，但是从事务执行成功了，业务逻辑就会发生错乱。

5、RocketMQ 如何保证事务消息在消费端正常消费

6、事务消息的适用场景

第一类场景：需要同步执行的领域事件，比如说领域事件逻辑失败概率大，业务要及时将返回码告知客户端，自然不能放在异步流程中。举个例子，做过支付系统的小伙伴都知道，支付扣款前要检查余额是否足够，如果余额不足，那在异步流程中重试多少次都是失败。 第二类场景：是事务不可重入场景，例如业务系统发送消息时没有确定一个唯一事务 ID，那后续的业务逻辑就无法保证幂等，假设其中一个事务是创建订单，如果不能保证幂等的话，重试多次就会产生多个订单；所以这里需要使用到事务消息，用来明确一个分布式事务的开始，生成一个唯一事务 ID，让后续的流程能以这个事务 ID 来保证幂等。

未来规划

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。