针对不同的应用场景，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 注解指定事务各阶段具体的实现接口。