之前我们已经针对四种分布式事务模式AT,TCC,SAGA,XA进行了详解。本篇主要针对四种模式的应用场景进行总结比较。如果想详细了解四种模式的，可以看看专栏往期博文：
springcloud进阶：四种分布式事务模式之AT模式（一）
springcloud进阶：四种分布式事务模式之TCC模式（二）
springcloud进阶：四种分布式事务模式之SAGA模式（三）
springcloud进阶：四种分布式事务模式之XA模式（四） 
-
易用性 从易用性上来看AT和XA模式是最容易上手的，他们都是无代码入侵的，基于seata的实现中只需要添加上
@GlobalTransactional注解即可。而TCC和SAGA都是需要自己实现业务代码的，使用起来相对较难。 -
数据一致性 XA模式需要等到所有事务执行完成后才释放本地锁，所以是四个模式中数据一致性最强的；AT模式采取全局锁和本地锁结合使用，所以数据一致性也得以保障，当然不如XA模式这样强。TCC模式与SAGA都是自己实现业务代码，因此一致性上较其他两种要弱些，特别是SAGA模式的长事务，更容易引起脏读
-
性能性 不加锁的性能一定最佳，数据一致性和性能一直是一个相对概念，因此TCC模式性能相对最高，SAGA因为本身是对长事务的支持，从执行时间上看并不占用，但单看执行性能，因为没有锁，所以仅次之TCC。XA是等到所有事务执行完成后才释放本地锁，所以性能最差
AT模式是实际开发中最常用的模式，他无代码入侵的特性，适应于不希望对代码进行改造的场景，因为AT模式要求数据库是支持本地事务的数据库，但是因为市面上多数使用的都是支持事务的数据库，所以其应用也十分广泛。
同时AT模式采用全局锁的概念，在本地事务执行完成后就会释放本地锁。所以性能也有一定的保障。
综上，AT适用的场景：
- 不希望对代码进行改造的场景
- 数据库支持事务操作，这是必要条件
- 对性能没有特别高要求的业务
TCC中没有全局锁，通过自己实现try-confirm-cancel三个方法的业务代码来实现事务。所以TCC模式的应用场景：
- 对性能有较高要求的业务场景
- 存储库不支持事务的场景
- 支持跨服务：这一点之前没有提到，seata的AT模式是不能跨服务的（这里的服务特指系统级别的服务，可以理解为系统，非常规理解的微服务），但是因为TCC的二阶段代码都是我们自己实现的，所以跨服务跨平台都可以自主实现
SAGA模式专用于解决长事务业务场景。不用等到事务执行完成后才释放锁定的资源。综上，SAGA模式适用于
- 长事务业务场景
- 适用于需要接入老服务、第三方服务或者其他无法改造的服务的业务场景
- 需要操作更细分散在多个服务、系统中的数据的业务场景
XA模式与AT模式的区别在与XA模式需要在所有事务执行完成后才释放本地锁，所以XA模式适用于：
- 对性能要求低，但要求强一致性的业务场景。
