常见的分布式事务解决方案有哪些？

从是否满足事务 ACID 特性上，我们可以将事务分为两大类：刚性事务和柔性事务。 在常见解决方案中 XA 事务属于刚性事务解决方案，而其他的大多数解决方案如 TCC、 Saga、消息最终一致性则属于柔性事务解决方案。以下将对几种常见的事务方案做简要的 介绍：

消息最终一致性

消息最终一致性方案是在 Seata 问世之前，市面上应用最广泛的一种解决方案。它本 身具有削峰填谷，可异步化的优点，更多的适应于可异步化的末端链路消息通知场景。但是 它本身也存在着一些缺点：需要依赖可靠消息组件，消息的可靠性很重要，大多数的原生消 息组件故障时很难降级；实时性比较差，要经过多次网络 IO 开销和持久化，遇到队列积压 情形实时性不可控；无法保证隔离性，在已发送消息和消息消费之前，中间数据对外可见， 无法满足事务 isolate 特性；只能向前重试不可向后回滚，消息消费无法成功时无法回滚 消息生产侧的数据；无法保证多条消息间的数据一致性。

XA

XA 标准提出后的 20 多年间未能得到持续的演进，在学术界有协议优化和日志协同处 理等相关的研究，在工业界使用 XA 落地方案的相对较少，主要集中在应用服务器的场景。 XA 方案要求相关的厂商提供其具体协议的实现，目前大部分关系数据库支持了 XA 协议， 但是支持程度不尽相同，例如，MySQL 在 5.7 才对 xa_prepare 语义做了完整支持。 XA 方案被人诟病的是其性能，其实更为严重的是对于连接资源的占用，导致在高并发未有 足够的连接资源来响应请求成为系统的瓶颈。在微服务架构下 XA 事务方案随着微服务链 路的扩展成为一种反伸缩模式，进一步加剧了资源的占用。另外 XA 事务方案要求事务链 路中的 resource 全部实现 XA 协议方可使用，若其中某一资源不满足，那么就无法保证整 个链路的数据一致性。

TCC

TCC 方案要求用户根据业务场景实现 try，confirm，cancel 三个接口，由框架根据 事务所处的事务阶段和决议来自动调用用户实现的三个接口。从概念上 TCC 框架可以认为 是一种万能框架，但是其难点是业务对于这三个接口的实现，开发成本相对较高，有较多业 务难以做资源预留相关的逻辑处理，以及是否需要在预留资源的同时从业务层面来保证隔离 性。因此，这种模式比较适应于金融场景中易于做资源预留的扣减模型。

Saga

有了 TCC 解决方案为什么还需要 Saga 事务解决方案？上文提到了 TCC 方案中 对业务的改造成本较大，对于内部系统可以自上而下大刀阔斧的推进系统的改造，但对于第 三方的接口的调用往往很难推动第三方进行 TCC 的改造，让对方为了你这一个用户去改 造 TCC 方案而其他用户并不需要，需求上明显也是不合理的。要求第三方业务接口提供 正反接口比如扣款和退款，在异常场景下必要的数据冲正是合理的。另外，Saga 方案更 加适应于工作流式的长事务方案并且可异步化。

上面提到了 4 种常用的分布式事务解决方案，Seata 集成了 TCC、Saga 和 XA 方 案