谈谈你对 Seata 的理解

普通人

Seata 是用来解决分布式事务问题的框架。是阿里开源的中间件。

实际项目中我没有用过，我记得 Seata 里面有几种事务模型，有一种 AT 模式、

还有 TCC 模式。

然后 AT 是一种二阶段提交的事务，它是采用的最终一致性来实现数据的一致性。

高手

在微服务架构下，由于数据库和应用服务的拆分，导致原本一个事务单元中的多

个 DML 操作，变成了跨进程或者跨数据库的多个事务单元的多个 DML 操作，

而传统的数据库事务无法解决这类的问题，所以就引出了分布式事务的概念。

分布式事务本质上要解决的就是跨网络节点的多个事务的数据一致性问题，业内

常见的解决方法有两种

强一致性，就是所有的事务参与者要么全部成功，要么全部失败，全局事务协调

者需要知道每个事务参与者的执行状态，再根据状态来决定数据的提交或者回滚！

最终一致性，也叫弱一致性，也就是多个网络节点的数据允许出现不一致的情况，

但是在最终的某个时间点会达成数据一致。

基于 CAP 定理我们可以知道，强一致性方案对于应用的性能和可用性会有影响，

所以对于数据一致性要求不高的场景，就会采用最终一致性算法。

在分布式事务的实现上，对于强一致性，我们可以通过基于 XA 协议下的二阶段

提交来实现，对于弱一致性，可以基于 TCC 事务模型、可靠性消息模型等方案

来实现。

市面上有很多针对这些理论模型实现的分布式事务框架，我们可以在应用中集成

这些框架来实现分布式事务。

而 Seata 就是其中一种，它是阿里开源的分布式事务解决方案，提供了高性能

且简单易用的分布式事务服务。

Seata 中封装了四种分布式事务模式，分别是：

AT 模式，是一种基于本地事务+二阶段协议来实现的最终数据一致性方案，也是

Seata 默认的解决方案

TCC 模式，TCC 事务是 Try、Confirm、Cancel 三个词语的缩写，简单理解就

是把一个完整的业务逻辑拆分成三个阶段，然后通过事务管理器在业务逻辑层面

根据每个分支事务的执行情况分别调用该业务的 Confirm 或者 Cacel 方法。

Saga 模式，Saga 模式是 SEATA 提供的长事务解决方案，在 Saga 模式中，业

务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经

成功的参与者。

XA 模式，XA 可以认为是一种强一致性的事务解决方法，它利用事务资源（数

据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一

种事务模式。

从这四种模型中不难看出，在不同的业务场景中，我们可以使用 Seata 的不同

事务模型来解决不同业务场景中的分布式事务问题，因此我们可以认为 Seata

是一个一站式的分布式事务解决方案