针对不同的应用场景,GTS 主要提供标准模式(AT)和自定义模式(MT)两种事务模式。

  • AT 模式:是 GTS 最主要的事务模式,通过 GTS 基于 MySQL/RDS 的数据源,对 SQL 语句提供分布式事务支持。它帮助应用方以最小的改造代价来实现数据库的事务功能。

  • MT(TCC) 模式:提供用户可以介入两阶段提交过程的一种模式。在这种模式下,用户可以根据自身业务需求自定义在 GTS 的两阶段中每个阶段的具体行为。MT 模式提供了更多的灵活性,可能性,以达到特殊场景下的自定义优化,及特殊功能的实现。

    MT 模式不依赖于数据库,这是它相对于 AT 模式的一个最大的优势。MT 模式几乎满足任何事务场景。

在 AT 和 MT 这两种模式下,GTS 又提供了三种具体的使用方式:

  • AT 模式下,在用户代码中使用注解接入分布式事务

    这种方式需要在代码中依赖 GTS 的 SDK,在希望引入分布式事务的方法上,仅需一行注解就可以轻松实现分布式事务。适用的场景包括跨数据库事务、MQ 的消息事务、EDAS 的服务事务及多场景混合型事务方案。

  • AT 模式下,DRDS 中接入分布式事务

    与 DRDS < 5.2.x 版本集成使用时无需 @TxcTransaction 注解,且无需引入 GTS 的 SDK,仅需要在用户的 SQL 语句中使用 select last_txc_xid() 这条 SQL 语句接入 GTS 分布式事务。通过这种方式,用户在使用 DRDS 实现分库分表后,就可以使用 GTS 实现和传统单机数据库一致的分布式事务。

    说明:除了 DRDS 独立使用 GTS 的场景,还有一种情况,即在 EDAS 上使用 DRDS,这种情况下,可以把 DRDS 看做一个普通的数据库,通过注解方式来使用 GTS。

  • MT 模式下,通过两阶段提交接入分布式事务

    允许应用介入事务的两阶段提交,分为补偿型事务和预留型事务两类。

    • 补偿型事务:应用需要在第一阶段实现具体的业务操作,第二阶段实现提交或者回滚操作。
    • 预留型事务:应用需要在第一阶段预留业务资源,第二阶段提交时实现真正的业务逻辑或者回滚。

    MT 模式下,每一个业务表需要建立一个临时表。通过 @MtBranch 注解指定事务各阶段具体的实现接口。