深度剖析分布式事务之 AT 与 XA 对比

AT 这种事务模式是阿里开源的seata主推的事务模式,本文会详解AT的原理,并将它与XA模式进行比较

原理

AT 从原理上面看,与 XA 的设计有很多相近之处。XA 是数据库层面实现的二阶段提交, AT 则是应用/驱动层实现的二阶段提交。建议您了解了XA相关的知识后,来阅读这篇文章,这样能够更快更好的掌握 AT 的原理与设计。

AT的角色和XA一样分为3个,但是起了不一样的名称,大家注意分辨:

  • RM 资源管理器,是业务服务,负责本地数据库的管理,与XA中的RM一致
  • TC 事务协调器,是Seata服务器,负责全局事务的状态管理,负责协调各个事务分支的执行,相当于XA中的TM
  • TM 事务管理器,是业务服务,负责全局事务的发起,相当于XA中的APP

AT 的第一阶段为prepare,它在这一阶段会完成以下事情:

  1. RM 侧,用户开启本地事务
  2. RM 侧,用户每进行一次业务数据修改,假设是一个update语句,那么 AT 会做以下内容:

    1. 根据update的条件,查询出修改前的数据,该数据称为BeforeImage
    2. 执行update语句,根据BeforeImage中的主键,查询出修改后的数据,该数据称为AfterImage
    3. 将BeforeImage和AfterImage保存到一张undolog表
    4. 将BeforeImage中的主键以及表名,该数据称为lockKey,记录下来,留待后续使用
  3. RM 侧,用户提交本地事务时,AT 会做以下内容:

    1. 将2.4中记录的所有的lockKey,注册到 TC(即事务管理器seata)上
    2. 3.1中的注册处理会检查 TC 中,是否已存在冲突的主键+表名,如果有冲突,那么AT会睡眠等待后重试,没有冲突则保存
    3. 3.1成功完成后,提交本地事务

如果 AT 的第一阶段所有分支都没有错误,那么会进行第二阶段的commit,AT 会做以下内容:

  1. TC 会将当前这个全局事务所有相关的lockKey删除
  2. TC 通知与当前这个全局事务相关的所有业务服务,告知全局事务已成功,可以删除undolog中保存的数据
  3. RM 收到通知后,删除undolog中的数据

如果 AT 的第一阶段有分支出错,那么会进行第二阶段的rollback,AT 会做以下内容:

  1. TC 通知与当前这个全局事务相关的所有业务服务,告知全局事务失败,执行回滚
  2. RM 收到通知后,对本地数据的修改进行回滚,回滚原理如下:

    1. 从undolog中取出修改前后的BeforeImage和AfterImage
    2. 如果AfterImage与数据库中的当前记录校验一致,那么使用BeforeImage中的数据覆盖当前记录
    3. 如果AfterImage与数据库中的当前记录不一致,那么这个时候发生了脏回滚,此时需要人工介入解决
  3. TC 待全局事务所有的分支,都完成了回滚,TC 将此全局事务所有的lockKey删除

问题分析

AT 模式的一个突出问题是rollback中2.3的脏回滚难以避免。以下步骤能够触发该脏回滚:

  1. 全局事务g1对数据行A1进行修改 v1 -> v2
  2. 另一个服务将对数据行A1进行修改 v2 -> v3
  3. 全局事务g1回滚,发现数据行A1的当前数据为v3,不等于AfterImage中的v2,回滚失败

这个脏回滚一旦发生,那么分布式事务框架没有办法保证数据的一致性了,必须要人工介入处理。想要避免脏回滚,需要把所有对这个表的写访问,都加上特殊处理(在Seata的Java客户端中,需要加上GlobalLock注解)。这种约束对于一个上了一定规模的复杂系统,是非常难以保证的。

AT vs XA

上述脏回滚问题,在 XA 事务中不会出现,因为 XA 事务是在数据库层面实现的,当另一个服务对为数据行A1进行修改时,会因为行锁被阻塞,与普通事务的表现完全一样,不会产生问题。

另外 XA 不会发生脏读,而 AT 会发生脏读,考虑AT下的如下执行步骤:

  1. 全局事务g1对数据行A1进行修改 v1 -> v2
  2. 另一个服务将读取数据行A1,获得数据 v2
  3. 全局事务g1回滚,将数据行A1改回 v2 -> v1

这里面步骤2读取的数据是v2,是一个中间态数据。在Seata的手册中,虽然也有一些方法能够避免AT模式下,但是涉及到注解和sql改写,并不优雅。而在XA模式下,由于还没有进行xa commit,那么步骤2根据MVCC读取到的数据依然是v1,没有AT模式中的脏读的困扰。

性能分析

从原理的详细步骤看,XA事务的性能高于AT,分析如下:

AT 模式下,RM侧,上述原理过程中,执行的SQL如下:

  1. 开启事务
  2. 查询BeforeImage数据
  3. 执行update
  4. 查询AfterImage数据
  5. 将BeforeImage,AfterImage插入到undolog中
  6. 提交事务
  7. 事务完成后,删除BeforeImage和AfterImage

而 XA 模式下,RM侧,执行的SQL如下:

  1. xa begin
  2. 执行update
  3. xa end
  4. xa prepare
  5. xa commit

两者对比,相关的开启/提交事务是两个模式都需要的,性能差异不大。但是从执行的DML操作来看,AT 下的 SQL 数量为:3 writes,2 read,比 XA 下仅一个update多出许多,因此在性能上会有较大的差距

从上述理论分析,XA 事务性能会大幅高于AT,应当可以在postgres数据库上验证出来;而mysql数据库,在当前的5.8版本上,由于xa prepare后,需要将当前连接断开才能够在其他连接上xa commit,所以会有一个重新创建连接的开销,最终性能对比参考下一节。

性能实测

上述进行了理论上的性能分析,我同时也做了性能实测,详细的测试过程和结果数据,参考 xa-at bench

dtm实现的XA事务,为了在极端情况下,也能保证XA事务能够正确的被清理,会在业务事务中对子事务屏障表进行插入,因此会比上述理论分析中,多一个sql写入。

我们可以看到,最终的结果XA性能优于AT。如果未来Mysql完善了XA的实现,可以不用关闭当前连接也能够允许其他连接提交xa事务,那么XA的性能还能够提升一大截。

AT的意义

mysql在版本5.6中,xa相关API存在bug。如果当前连接在xa prepare之后,连接断开,那么这个连接未完成的事务会被自动回滚。这样的bug导致mysql的XA模式是无法保证正确性的,在各种应用crash中,可能导致数据不一致。因此AT在mysql的5.6版本及更低版本使用中,是具有很高应用价值的。

另外部分大厂的数据库是禁止使用XA事务的,这种特定场景下,选型AT模式,也是合理的。

对于其他场景,建议优先考虑 XA 事务。

小结

作者对AT模式的完整实现源码,并未完整阅读。上述的相关原理是根据自己阅读相关资料,并参考了seata-golang的源代码而写。文中如果不准确之处,希望各位读者帮忙指正

欢迎访问 https://github.com/dtm-labs/dtm 并star支持我们

你可能感兴趣的:(深度剖析分布式事务之 AT 与 XA 对比)