全部产品
云市场

参与者接入模式

更新时间:2020-03-13 12:29:40

使用分布式事务涉及两个核心角色:

  • 发起方:指的是开启分布式事务的应用系统。
  • 参与者:指的是提供分支事务的应用系统。同一个应用系统可能兼具发起方和参与方两个角色。

分布式事务目前提供了两种参与者接入模式:TCC 模式与 FMT 模式。

TCC 模式

TCC(Try-Confirm-Cancel)是一种高性能的分布式事务接入方案,该模式提供了更多的灵活性,几乎可满足任何您能想到的事务场景。TCC 模式提供自定义补偿型事务、自定义资源预留型事务、消息事务等场景,用户可以介入两阶段提交的过程,以达到特殊场景下的自定义优化及特殊功能的实现。

TCC 模式架构如下:

architecture-TCC

特性

  • 最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。
  • 协议简单:TCC 模式定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 TCC 模式的事务功能。
  • 与 RPC 服务协议无关:在 SOA 架构下,一个或多个数据库操作往往被包装成一个或多个 Service,不同的 Service 之间通过 RPC 协议通信。TCC 模式构建在 SOA 架构上,与底层协议无关。
  • 与底层事务实现无关: TCC 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 TCC 的范围内,无论是关系型数据库 MySQL、Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 TCC 的参与者,就可以接入到 TCC 事务范围内。

FMT 模式

为了解决 TCC 模式的易用性问题,蚂蚁金服金融科技分布式事务推出了框架管理事务模式(Framework-managed transactions,简称 FMT)。FMT 是一种无侵入的分布式事务解决方案,该模式解决了分布式事务的易用性问题,最大的特点是易于使用、快速接入以及对业务代码无侵入。

FMT 模式架构如下:

architecture-FMT

接入模式特性对比

事务 TCC 模式 FMT 模式
事务 ACID 属性 原子性(Atomicity) 2PC 算法,框架实现两阶段调用,业务实现两阶段接口 2PC 算法,框架实现
一致性(Consistency) 天然实现 天然实现
隔离性(Isolation) 放宽一致性协议,最终一致,所以是读已修改 1. 读加锁,串行化隔离级别
2. 读不加锁,读已修改隔离级别
持久性(Durability) 天然实现 天然实现
写并发控制 加锁,业务实现,资源锁+业务锁 加锁,资源锁+框架行锁
CAP 一致性 放宽一致性协议,最终一致 1. 读写加锁,强一致
2. 读不加锁,最终一致

接入模式效率对比

以转账场景为例,对比分布式事务的 TCC 模式与 FMT 模式的接入效率。

FMT 接入用时

变更项目 变更详细 用时(分钟) 说明
配置分布式事务环境 添加 maven 依赖 10 添加分布式事务的 maven 依赖
配置分布式事务环境 添加分布式事务扫描类 10 添加分布式事务扫描 bean
数据源配置 数据源 bean 配置 10 配置分布式事务数据源
数据源配置 数据源 DDL 变更 10 业务数据中创建 dtx_branch_infodtx_row_lock
发起方接入 发起方代码配置 10 发起方方法上添加分布式事务注解

合计: 50 分钟

TCC 接入用时

变更项目 变更详细 用时(分钟) 说明
配置分布式事务环境 添加 maven 依赖 10 添加分布式事务的 maven 依赖
配置分布式事务环境 添加分布式事务代码配置 10 添加分布式事务扫描 bean
参与者接入×2 TCC 参与者定义 10 定义加钱参与者、扣钱参与者接口
参与者接入×2 TCC 参与者实现 8×60 按转账场景计算,需要分别实现加钱参与者和扣钱参与者
参与者接入×2 TCC 参与者服务发布 10 发布成 SOFARPC 服务、或者 Dubbo 服务
TCC 防悬挂接入×2 TCC 防悬挂 DDL 变更 10 业务库中创建防悬挂表 dtx_tcc_action
TCC 防悬挂接入×2 TCC 防悬挂 DAO 配置 10 配置防悬挂 DAO bean
TCC 防悬挂接入×2 TCC 参与者实现变更 10 包括 TCC 参与者接口定义及其实现变更
发起方接入 发起方代码配置 10 发起方方法上添加分布式事务注解

合计: 560 分钟

接入效率总结

  • 在转账业务场景下,FMT 模式接入用时 50 分钟,TCC 模式接入用时 560 分钟。TCC 模式接入耗时比 FMT 模式多 10 倍左右。
  • TCC 模式接入耗时主要集中在 TCC 参与者的设计和实现上,这一项的工作量视业务场景负责程度而定。
  • 在本文的转账场景下,需要实现 2 个参与者,分别为“加钱”与“扣钱”参与者,每个参与者又分别有 3 个方法需要实现,故预估时间为 1 个工作日。