金融级分布式事务解决方案DTC

金融级分布式事务解决方案 DTC

作者简介:英文名 tom,14 年以上的研发经验,5 年的金融领域架构研发经验。目前从事金融软件架构工作,专注于高并发、高性能、分布式、微服务领域。

DTC 架构说明

DTC(全称 distributed-transaction-coordinator),分布式事务协调器。是一款基于金融业务领域而研发的全新分布式事务中间件。DTC 的设计初衷是为了解决金融业务的账务交易一致性的问题,笔者最近几年一直从事金融业务系统的架构和研发,对金融业务有着较深的理解,DTC 是基于金融交易中出现的需求而开发。

业务背景说明

根据金融交易业务的要求,在跨组件交易的过程中,需要保证所有的组件要么全部成功要么全部失败。在交易失败后出现不一致的情况,能够通过同步和异步以及人工介入的方式保证交易最终的一致性。所以保证交易一致性需要满足以下的条件:

  1. 各个业务组件需要保证内部正交易和冲正交易的一致性和幂等性
  2. 需要设计多种处理方式来满足最终交易的一致性:

(1) 接口重试 (2) 自动同步冲正 (3) 自动异步冲正 (4) 支持手工查询和手工冲正

金融领域常见的交易不一致的现象总结:

在金融交易系统里,对于交易不一致性常见的处理方式:

金融交易系统一致性的设计原则:

  1. 业务系统需要有一个全局唯一的业务流水号,所有的交易组件都要对流水号进行验重并记录,用以追溯交易的状态
  2. 调用方主导原则,调用方需要对异常状况进行处理,根据异常处理策略进行重试/冲正
  3. 先借后贷原则,在出现单边帐的情况下,可以采用不明确时先冻结,后续问题解决再解冻的原则,避免损失
  4. 超时漏斗设计的原则,这样可以避免多点超时引起重试或者冲正
  5. 要有系统的故障自动隔离机制
  6. 要有对系统的流控机制,避免系统超负载引起系统不可用。根据这些业务的特点,我设计了一个针对于专门处理金融交易分布式事务的框架 DTC。

DTC 架构设计

DTC 总体架构图

DTC 的组件

DTC Server:DTC Server 是 DTC 的核心部件,DTC Server 的功能是接收 Sponsor 的分布式事务请求,然后对请求的参数进行校验。校验通过后,将请求的数据转换为分布式的 bean(全局事务 bean、分支事务 bean),并且保存到数据库表中。数据保存成功后根据分布式事务模型进行分支事务的调用。如果分支事务执行成功则更新分支事务的状态,如果分支事务全部成功则更新全局事务为成功状态,如果分支事务执行失败则回滚分支事务,并更新全局事务的状态。最后将执行结果返回给 Sponsor。

DTC server 架构图

DTC Sponsor:Sponsor 是负责接入外部的业务请求,按照业务请求根据编排模型,将业务数据组装为事务的数据模型。通过 GRPC 接口发送给 Server,Server 处理之后将结果返回给 Sponsor。Sponsor 将结果返回给外部请求的服务。

DTC Actuator:Acutator 是分支事务的默认实现,如果分支业务方使用的是 java 语言,可以通过实现相关的接口实现业务逻辑即可。Acutator 会负责和 server 之间的通信,事务的执行。目前 Acutator 支持的事务模型是 TCC 和 XA,对 saga 模型,如果是 java 语言开发,业务方可以依托 Actuator 来实现。简化调用。

DTC Compensator:Compensator 模块是负责补偿异常事务补偿的服务以及数据清理的工作。通过定时任务的机制查下失败的任务,根据分支任务的状态和全局任务的状态设置处理机制(冲正/重试)。Compensator 不负责具体的事务处理,而是将异常的任务发送给 Server,由 server 负责具体的异常事务的处理。Compensator 也会定时对数据表进行清理,保证数据表不至于过大导致性能严重下降。

DTC Adminadmin 模块是管理模块,可以对相关的数据进行管理(查询、修改、删除),支持手动执行事务的重试/冲正.

DTC 在金融交易中的流程

正交易处理流程

正交易业务流程图

流程说明:

  1. 外部系统发起正交易流程
  2. 通过网关进行权限校验以及限流然后进入 dtc 的处理流程
  3. 根据交易的业务流水进行验重,如果已经存在则返回重复交易的错误
  4. 如果为新的交易则对相关的参数进行验证
  5. 参数验证完成后根据业务码加载对应的事务模型
  6. 将待执行的全局事务存入数据库表中
  7. 根据事务模型执行对应的分支事务
  8. 如果是 TCC/XA 模式则调用 prepare 接口
  9. 待所有的分支执行 prepare 完成后,如果全部执行成功则调用 commit 接口,否则调用 cancel 接口
  10. TCC/XA 模式下如果某个分支执行 commit 失败,则根据模型配置是否重试 commit
  11. 判断所有的分支执行状态,更新全局事务状态
  12. 如果是 saga 模式则调用 commit 接口,如果执行成功则继续下一个分支,如果所有的分支都执行成功则更新全局事务为成功,否则根据模型配置决定是否重试,否则执行进行同步冲正
  13. saga 模式如果同步冲正出错则中断执行
  14. 根据分支执行结果更新全局事务的状态
  15. 组装全局事务的结果返回给请求者。

冲正交易流程

冲正交易流程图

冲正交易流程说明:

  1. 外部系统发起冲正流程
  2. 通过网关进行权限校验以及限流然后进入 dtc 的处理流程
  3. 根据业务流水判断是否存在对应的正交易,如果不存在则返回交易不存在的错误
  4. 对冲正请求进行参数验证
  5. 从数据库加载对应的正交易事务
  6. 组装冲正交易请求
  7. 执行分支事务的冲正流程
  8. 判断分支是否需要冲正(排除 已经冲正成功/未执行的分支事务)
  9. 判断是否所有待冲正分支事务已经执行成功
  10. 更新全局事务的状态和冲正次数。

异步补偿流程

异步补偿流程图

流程说明:

  1. 异步补偿定时任务,获取分布式锁,如果获取成功则继续执行,否则放弃执行
  2. 加载数据库中的异常全局事务(包括执行次数少于最大重试次数,未超过最大执行时间)
  3. 如果是 initial 状态或者 running 状态的事务,则判断分支执行状态,如果尚未执行则调用分支执行 commit,如果执行 commit 失败则根据重试规则进行重试,重试失败则执行同步冲正。
  4. 如果是提交失败或者冲正失败则执行冲正流程,加载所有未进行充值的分支分别调用冲正接口进行冲正。
  5. 判断待执行的分支都已经执行完毕,如果成功则更新全局事务为成功状态,否则更新为冲正失败。
  6. 更新全局事务的执行次数。

DTC 的架构特点

  1. 所有的组件都是基于无中心化的设计,所有组件都支持自由扩展
  2. 以 server 为中心处理分布式事务,分布式事务实现简单
  3. 对于 TCC/XA 模式可以通过引入 acuator 组件,实现快速开发
  4. 支持分布式事务模型的灵活扩展,如果是 java 语言开发的业务系统,则可基于 spi 的方式实现,其他语言开发的业务系统则通过 http 的方式对接
  5. 支持 tcc/saga/xa 等常见的分布式事务模型
  6. 组件内部数据流转和接口调用尽量异步化,提高交互性能
  7. 通过 rest 接口和外部系统对接,减少系统之间的耦合
  8. 通过模型编排,可以自由编排 TCC/saga 的调用接口和参数以及重试、超时规则

待优化的点

  1. 基于应用场景有限,尚未经过大规模的性能测试
  2. 支持的事务模式不足目前支持三种:TCC/SAGA/XA
  3. 任务编排还没有相关的前端界面支持
  4. 还没有监控设计以及监控前端
  5. 缺少管理界面
  6. 缺少微服务治理的限流、鉴权等功能

DTC 与其他分布式事务框架的区别

  • DTC 紧贴金融交易业务,根据金融交易的特点而开发
  • 基于 DTC 的开发分布式事务更加的简单
  • DTC 的部署相对更加容易
  • DTC 的基于服务编排的方式实现分布式事务,支持分布式事务的简单灵活实现(接口的自由扩展,参数的可配置等)

DTC 的开源地址

https://github.com/tomzlh/distributed-transaction-coordinator

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/c1979d096ca70cdd1852aa081
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券