分布式事务 Seata

分布式事务的介绍

事务是数据的概念，数据事务(ACID:原子性，一致性，隔离性，持久性)；

        分布式事务的产生，是由于数据库的拆分和分布式架构（微服务）带来的，在常规情况下，我们在一个进程中操作一个数据库，这属于本地事务，如果在一个进程中操作多个数据，或者在多个进程中操作一个或者多个数据库（并发问题），就产生了分布式事务；

我们说，分布式事务是由一批分支事务组成的全局事务，通常分支事务就是本地事务。

也就是在保证同时操作的时候的一致性（数据的一致性）。

（1）数据库分库分表产生了分布式事务；

（2）项目拆分服务化也产生了分布式事务；

seata 的介绍

        Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提高性能和简单易用的分布式事务服务；

        Seate为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案；

        四种事务模式中，XA模式正在开发中....,其他事务模式已经实现；目前使用流行度情况是：AT>TCC>Saga；

我们可以参看seata各个公司使用列表 ；

Wanted: who's using Seata · Issue #1246 · apache/incubator-seata · GitHub大部分公司都采用的AT事务模式；

Seata 已经在国内很多团队开始落地，其中不乏有大公司；

Github：GitHub - apache/incubator-seata: :fire: Seata is an easy-to-use, high-performance, open source distributed transaction solution.

官网：Apache Seata

在Seata的架构中，一共有三个角色：

TC（Transaction Coordinator ）- 事务协调者

        维护全局和分之事务的状态，驱动全局事务提交或回滚；他会保存相关服务的注册信息，id，名称。它的作用时用来将各个服务进行调度的和协调操作的。比如发起方向TC发起提交后，其他的服务都需要进行提交事务。通过它进行通知调度。它是一个单独的服务

TM(Transaction Manager ) - 事务管理器

        定义全局事务的范围：开始全局事务、提交或者回滚全局事务；（也就是事务的发起方）

RM（Resource Manager） - 资源管理器

        管理分支事务处理的资源，与 TC 交互以注册分支事务和报告分支的状态，并驱动分支事务提交回滚。

注意：其中TC为单独的部署的Server 服务端，TM和RM为嵌入到应用中Client 客户端；

在Seata 中，一个分布式事务的生命周期如下：

TM 请求 TC 开启一个全局事务，TC会生成一个 XID 作为该全局事务的编号，XID 会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起；RM请求 TC 将本地事务注册为全局事务的分支事务，通过全局事务的 XID 进行关联；

TM 请求 TC 告诉 XID 对应的全局事务是否进行提交还是回滚；

TC 驱动 RM 将 XID 对应的自己的本地事务进行提交还是回滚；

常见的分布式解决方案

介绍

1、seata 阿里巴巴分布式框架

2、消息队列

3、sage

4、XA

        他们有一个共同点，都是 “两阶段(2PC)”,“两阶段”是支持完成整个分布式事务，划分俩个步骤完成。实际上，这四种常见的分布式事务解决方案，分别对应着分布式事务的四种特性：AT、 TCC、Sage 、XA ； 四种分布式事务模式，都有各自的理论进出，分别在不同的时间被提出：每种模式都有它的适用场景，同样每个模式也诞生各自的代表产品；而这些代表产品，可能就是我们常见的全局事务，基于可靠消息、最大努力通知 TCC。

分布式事务理论基础

解决分布式，也有相应的规范和协议，分布式事务相关的协议有 2PC 、3PC。

由于 三阶段提交提交协议3PC 非常难实现，目前市面上主流的分布式事务解决方案都是 2PC协议，这是开始介绍的的分布式解决方案中的，哪些列举的都有一个共同特点“两阶段”的内在原因。

有些文章分析 2PC 时，几乎都会用 TCC 两个阶段的例子，第一阶段 try 第二阶段完成 comfirm 或 cancel 。其实 2PC 并不是 专为实现 TCC 设计的，2PC 具有普适性----协议一样的存在，目前大多数分布式解决方案都是以两阶段提交协议 2PC 为基础的。

TCC （Try-Confirm -Canncel ）实际上是服务划分的俩个阶段提交协议。

2PC 的问题

1、同步堵塞，参与者在等待协调者的指令时，其实在等待其他参与者的响应，在此过程中，参与者无法进行其他的操作的，也就是堵塞了其他运行。倘若参与者与协调者之间网络异常导致参与者一直收不到协调者信息，那么会导致参与者一直堵塞下去。

2、单点 在2PC中，一切请求都来自协调者，所以协调者的地位只管重要的，如果协调者宕机，那么就会使参与者线程一直堵塞一直占用事务资源。如果协调者也是分布式，使用选主方式提供服务，那么这个协调者挂掉后，可以选取另一个协调者接着后续的服务，可以解决单点故障问题。但是，新协调者无法上个事务的全部状态(例如已经等待Prepare 响应的时长等)，所以也无法顺利处理上一个事务。

3、数据不一致 Commit 事务过程中 Commit 请求 /Rollback 操作，请求可能因为协调者宕机与参与网络问题丢失，那么就导致了部分参与者没有 Commit /Rollback 请求，而其他参与者则正常接收到执行 Commit /Rollback 操作，没有收到请求的参与者则接着堵塞，这时，参与者之间的数据不在一致。

当参与者执行 Commit /Rollback 后会向协调者发送ACK，然而协调者无论是否接收到所有参与者的ACK，该事务也不会再有其他补救措施了，协调者能做的也就是等待超时后事务发起者返回一个“我不确定事务是否成功”。