分布式常见面试题：聊聊分布式事务下的AT模式：优点、原理与局限

在分布式系统开发中，分布式事务的处理一直是个关键且复杂的问题。常见的分布式事务处理模式有XA模式（基于数据库的事务）、TCC（基于补偿模式），还有今天要重点探讨的AT模式。AT模式由阿里的Seata推出，在实际项目中应用广泛。最近我在处理一个分布式事务时使用了AT模式，体验下来感觉确实不错，就像Seata文档里描述的那样，它几乎没有代码侵入，使用起来很方便。下面我就详细给大家讲讲AT模式。

一、AT模式的便捷使用方式

AT模式最大的优势之一就是使用简单。在项目里，我们只需要引入一些简单的依赖，然后添加@Globaltransactional注解，Seata事务管理器就能自动帮我们管理事务。这对于开发者来说，无疑大大减少了开发成本，不用再像以前那样为了实现事务管理而编写大量复杂的代码。

二、AT模式的工作原理详解

AT模式的工作过程主要分为两个阶段。

1. 第一阶段：数据提交与操作记录
   当一个业务操作涉及多个数据库操作分支时，比如下单操作既涉及扣减库存，又涉及创建订单。在这个阶段，@Globaltransactional注解会通过AOP（面向切面编程）技术，对每个数据库操作分支进行切面拦截。简单来说，就是把所有对数据库的操作都记录下来，不过这些记录不是传统数据库级别的回滚日志，而是Seata自己解析SQL语句后形成的undolog日志，undolog详细记录了每一个操作步骤。
2. 第二阶段：事务结果判断与处理
   在这一阶段，系统会判断各个操作分支是否都成功执行。如果所有分支都成功了，那么之前记录的undolog回滚日志就会被直接删除，全局锁也会被释放，这样其他事务操作就可以顺利进行了。但要是有任何一个分支操作失败，系统就会执行对应分支的undolog回滚日志。比如之前扣减的库存，就要恢复到原来的数值；创建的订单，也得取消掉，以此来保证数据的一致性。

三、AT模式的性能局限

虽然AT模式使用方便，原理也容易理解，但它并非完美无缺，在性能方面存在一定的局限性。例如，在一个事务执行过程中，比如正在进行下单、扣库存和创建订单的操作时，如果有其他线程想要读取相关数据，系统是不允许的。这是因为在当前事务未结束的情况下，全局锁会将其他线程阻挡在外，这样就容易产生阻塞问题。这意味着AT模式在一定程度上牺牲了并发能力，在一些对性能和并发要求较高的场景中，它可能就不太适用了。在这种情况下，更建议大家使用TCC等补偿型事务模式，虽然这类模式需要侵入代码，但在并发性能上表现更优。

分布式事务的AT模式在简单易用和无代码侵入方面表现出色，但在并发性能上有所不足。在实际项目开发中，我们需要根据业务场景的具体需求，综合考虑选择合适的分布式事务处理模式。要是大家在使用AT模式或者其他事务模式时遇到了问题，欢迎在评论区留言交流，一起探讨解决方案。

喜欢 (0)赏

【请潘老师喝杯Coffee吧！】

分享 (0)