一句话总结，就是既想要ACID，又想要分布式事务，以目前的条件来说基本不可能。所以所有解决分布式事务的方案，立足点都是最终一致性。因此不管从哪里提到了分布式事务，如果面试官问起来，你都可以先从理论上强调这一点。
分布式事务或者说跨库事务基本上都只能依赖于最终一致性，ACID 是不太可能的。比如说常见的 TCC、AT、SAGA，又或者比较罕见的延迟事务，其实都是追求最终一致性。
这里提到了 TCC、AT 和 SAGA 这些比较具体的方案，你就可以根据后面的内容来进一步解释，或者等面试官询问。
注意，如果面试官认为 XA 是支持 ACID 的，那么他可能会问：“难道没有什么能够保证 ACID 吗？”通过这种问题你就可以知道面试官的倾向了，那么你就可以抛开个人立场，回答 XA 事务。
有，XA 事务可以看作支持 ACID。
如果面试官直接问 XA，那么你就可以按照自己的真实想法来回答。
TCC是一个追求最终一致性的，而不是严格一致性的事务解决方案，他不满足ACID要求。
TCC是Try Confirm Cancel的缩写，他勉强也算是两阶段提交协议的一种实现。
Try：对应于两阶段提交协议的准备阶段，执行事务但是不提交Confirm：对应两阶段提交协议第二阶段的提交步骤Cancel：对于两阶段提交协议的回滚步骤
之所以给它一个新名字，完全是因为TCC强调的是业务自定义逻辑。也就是说Try是执行业务自定义逻辑，Confirm也是执行业务自定义逻辑，Cancel也是。
TCC在微服务架构里比较常用，这三个各自对应一个微服务调用。不过一些分库分表中间件也支持TCC模式，但是比较罕见。
