1 行业背景

基金公司核心业务主要分为:

• 投研线业务，即投资管理和行业研究业务，体现基金公司核心竞争力
• 市场线业务，即基金公司利用自身渠道和市场能力完成基金销售并做好客户服务

随互联网技术发展，基金销售渠道更加多元化，线上成为基金销售重要渠道。相比传统基金客户，线上渠道具有客户基数大，水平参差不齐的特点。对于那些还不成熟的客户，我们需要做好陪伴，让他们理解风险，理解投资。

2 RocketMQ 在陪伴体系中的应用

2.1 陪伴场景概述

基金建立了一套全方位多层次陪伴体系，从用户层面、市场层面和产品层面为用户提供投前、投中、投后的有温度的投资陪伴体验。

每个陪伴场景的达成，需要公司多个部门不同团队协同配合来完成。依赖与投研、合规、运营、大数据等上下游多个系统。

但这些系统采用不同技术架构，实现方式各异，若采用同步调用实现协同，耦合太高，不利扩展。

2.2 RocketMQ 解耦异构系统

RocketMQ 提供高效可靠的消息传递特性和发布订阅机制，非常适合用于这种上下游异构系统间的解耦。把原来基于文件、邮件的协作方式全部线上化、流程化和机制化，大大提升了陪伴输出效率。

对于这种涉及多方系统的协作，需要对消息进行合理地归类，以便进行过滤和索引。RocketMQ 提供的 Topic 和 Tags 就是用来做这事。

2.3 Topic 和 Tags 最佳实践

Topic 与 Tag 作为业务上用来归类的标识，分属一级分类、二级分类。这种层次化的分类标识与企业组织架构类似，可结合起来实现消息过滤。

对于陪伴系统的 Topic：

• 运营系统订阅运营类消息，这类消息打 TagA 标签
• 客服系统订阅客服类消息 TagB
• 陪伴编排系统订阅编排类消息 TagC

合规系统需要对运营和陪伴消息进行合规审查，因此它需要订阅 TagA 和 TagC，最后是数据中心，所有的消息都要处理，因此它需要监听所有 Tag。

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

3.1 金融场景概述

典型的金融场景 -- 优惠购。基金 APP 上申购基金可享受低至 0 折费率优惠，两种实现方式：

• 先充值基金 app 钱包，底层是替客户购买了一笔货币基金，然后再用基金钱包购买目标基金。这种方式需用户操作两次，较繁琐，易引起客单流失
• 优惠购，把两步购买基金封装成一次事务操作。对于投资者，开启优惠购服务后，操作少一步，投资更简单！

3.2 领域事件理论模型

领域事件指业务流程的一个步骤将导致进一步的业务操作，比如登录事件、基金购买事件。

领域模型里，领域事件事务采用最终一致性，弱一致性的一种。在领域模型映射到微服务系统架构时，微服务之间数据不必强一致，因此领域事件可解耦微服务。

依据是否跨微服务，可分为两种场景：

• 当领域事件发生在同一微服务。由于大部分事件发生在同一进程内，自身可很好控制事务。但若一个事件需要同时更新多个聚合，按DDD中一次事务只更新一个聚合的原则，就要引入事件总线，即eventbus模式
• 跨微服务。领域事件发生在微服务之间的场景较多，事件处理机制也更复杂。跨微服务的事件可推动业务流程或数据在不同子域或微服务间直接流转，因此需要一个协调者推进全局事务。跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、MQ、分布式事务等，其中具备事务消息功能的MQ是该解决方案的核心组件

2.3 分布式事务方案对比

基金业务场景，需解决的问题是事务一致性与服务解耦度之间的矛盾，因此目标是让主从事务解耦，保证核心逻辑稳定，同时不因解耦而牺牲最终一致性。可选解决方案：

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

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

• 引入 XA 事务，两阶段提交协议，实现难度较大。且面临两个问题：

  • 这是一种同步阻塞协议，有锁占用导致并发不会太高
  • XA 事务过程中，在参与者投赞成票后，若协调者故障，节点不清楚应该提交还是中止，只能等待协调者恢复。这时可能出现业务中断

• TCC，专门处理分布式事务，只侧重于一致性，无解耦度，也不可行

• 事务消息，兼顾解耦度和一致性，最合适

最终选择 RocketMQ 事务消息作为分布式事务解决方案：

4 RocketMQ 事务消息核心流程

基于 RocketMQ 的事务消息搭建事务中心，协调分布式事务的推进和回滚。

以优惠购为例的核心流程：

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

<code>@startuml

participant 业务系统

participant 事务中心

participant 主事务

participant 从事务

业务系统 -> 事务中心: Prepare

事务中心 --> 业务系统: OK

事务中心 -> 主事务: 执行（购买货币基金）

主事务 --> 事务中心: Return

alt 主事务执行成功

业务系统 -> 事务中心: Commit

事务中心 --> 业务系统: OK

loop 直到从事务执行成功

事务中心 -> 从事务: 执行（购买目标基金）

从事务 --> 事务中心: Return

end

else 主事务执行失败

业务系统 -> 事务中心: Rollback

事务中心 --> 业务系统: OK

end

@enduml

由于网络抖动等原因，可能导致事务消息的二次确认丢失。此时需依赖某种机制，恢复整个分布式事务的上下文，RocketMQ提供反查机制正是为解决分布式事务中的超时问题。

事务中心的反查机制流程

先检查事务中心的内部状态，再通过反查接口检查本地事务执行结果，恢复事务上下文后，正常推进后续的流程：

<code>@startuml

participant 业务系统

participant 事务中心

participant 主事务

participant 从事务

业务系统 -> 事务中心++: Prepare

事务中心 --> 业务系统--: OK

业务系统 -> 主事务++: 执行（购买货币基金）

主事务 --> 业务系统--: Return

业务系统 -> 业务系统:网络抖动

事务中心 --> 业务系统++: 反查接口

业务系统 -> 主事务++: 查询/执行事务

主事务 --> 业务系统--: Return

alt 主事务执行成功

业务系统 --> 事务中心++: Commit

end

@enduml

5 RocketMQ咋保证事务消息在消费端正常消费

Con消费失败后，broker需要进行一定次数重试，需制定合理重试策略。

因为消费重试，就要求Con接口实现幂等性；若重试多次后仍失败，把消息压入死信队列DLQ，RocketMQ内置死信队列功能，对进入死信队列的消息进行告警处理。

• 重试策略
• 幂等
• 死信队列
• 告警
• 业务介入

6 事务消息的适用场景

6.1 需同步执行的领域事件

若领域事件逻辑失败概率大，业务要及时将返回码告知客户端，自然不能放在异步流程。

如支付系统，支付扣款前要检查余额是否足够，若余额不足，异步流程中重试多少次都是失败。

6.2 事务不可重入场景

如业务系统发送消息时没有确定一个唯一事务ID，那后续业务逻辑就无法保证幂等。

假设其中一个事务是创建订单，若不能保证幂等，重试多次就产生多个订单；所以这里需要用到事务消息，明确一个分布式事务的开始，生成一个唯一事务 ID，让后续流程能以该事务 ID 保证幂等。

7 规划

支持事务消息的分布式消息队列，必然是数字化转型过程中的技术支柱，值得信赖！

目前，我们基于 RocketMQ 在客户陪伴体系上解耦了上下游的服务，提升了运营和陪伴的效率。同时，我们在 RocketMQ 事务消息的基础上，搭建了这样一个支持分布式事务的服务协调平台，也就是我们的事务中心，大大提升了对金融场景化的产品包装能力。未来，我们将围绕着事务中心，拓宽更多的金融应用场景，创造更大业务价值。

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。

各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

• 中央/分销预订系统性能优化
• 活动&券等营销中台建设
• 交易平台及数据中台等架构和开发设计
• 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
• LLM Agent应用开发
• 区块链应用开发
• 大数据开发挖掘经验
• 推荐系统项目

目前主攻市级软件项目设计、构建服务全社会的应用系统。

参考：

• 编程严选网

本文由博客一文多发平台 OpenWrite 发布！