1.1 事务的基本概念

就是一个程序执行单元，里面的操作要么全部执行成功，要么全部执行失败，不允许只成功一半另外一半执行失败的事情发生。例如一段事务代码做了两次数据库更新操作，那么这两次数据库操作要么全部执行成功，要么全部回滚。

1.2 事务的基本特性

我们知道事务有4个非常重要的特性，即我们常说的（ACID）。

Atomicity（原子性）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失

2 分布式事务

其实分布式事务从实质上看与数据库事务的概念是一致的，既然是事务也就需要满足事务的基本特性（ACID），只是分布式事务相对于本地事务而言其表现形式有很大的不同。

本地事务的时代，如果需要同时操作数据库的多条记录，而这些操作可以放到一个事务中，那么我们可以通过数据库提供的事务机制就可以实现。

而随着微服务架构的推进，原本一个本地逻辑执行单元，被拆分到了多个独立的微服务中，这些微服务又分别操作了不同的数据库和表。

比如下个指派个体的运输任务，下运输任务的同时要生成需求、计划、任务，还要去调用询价服务，投保服务，那么，一旦产生任何一个服务异常，都会产生事务性的问题。虽然对于我们现有逻辑来说，可以由运营作废，但未来自动化之后呢？

分布式事务是为了解决微服务架构（形式都是分布式系统）中不同节点之间的数据一致性问题。这个一致性问题本质上解决的也是传统事务需要解决的问题，即一个请求在多个微服务调用链中，所有服务的数据处理要么全部成功，要么全部回滚。当然分布式事务问题的形式可能与传统事务会有比较大的差异，但是问题本质是一致的，都是要求解决数据的一致性问题。

而分布式事务的实现方式有很多种，最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。XA协议包括两阶段提交（2PC）和三阶段提交（3PC）两种实现，接下来我们分别来介绍下这两种实现方式的原理。

3 两阶段提交（2PC）

两阶段提交又称2PC（two-phase commit protocol），2PC是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两个角色：一个是分布式事务协调者（coordinator）和N个参与者（participant）。

3.1 2PC运行原理

两阶段提交，顾名思义就是要进行两个阶段的提交：第一阶段，准备阶段（投票阶段）；第二阶段，提交阶段（执行阶段）。

3.1.1 准备阶段（Prepare phase）

分布式事务的发起方，向分布式事务协调者（Coordinator，也可以叫事务管理TransactionManager）发送请求，
Coordinator分别向参与者（Participant）A、参与者（Participant）B分别发送事务预处理请求，称之为Prepare，有些资料也叫”Vote Request”。
此时这些参与者节点一般来说就会打开本地数据库事务，然后开始执行数据库本地事务，每个数据库参与者在本地执行事务并写本地的Undo/Redo日志（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件），但在执行完成后并不会立马提交数据库本地事务，而是先向Coordinator进行“Vote Commit”的反馈，告知处理结果。
如果所有的参与者都向协调者做了“Vote Commit”的反馈的话，那么流程进入第二个阶段。

3.1.2 提交阶段（commit phase）

1）如果所有参与者均反馈的是成功，协调者就会向所有参与者发送“全局提交确认通知（global_commit）”，参与者Participant就会完成自身本地数据库事务的提交，并将提交结果回复“ack”消息给协调者Coordinator，然后协调者Coordinator就会向调用方返回分布式事务处理完成的结果。如果有任何一个参与者返回失败，则回滚事务。

2）如果参与者向协调者反馈“Vote_Abort”消息，即返回了失败的消息。此时分布式事务协调者Coordinator就会向所有的参与者Participant发起事务回滚的消息（“global_rollback”），此时各个参与者就会回滚本地事务，释放资源，并且向协调者发送“ack”确认消息，协调者就会向调用方返回分布式事务处理失败的结果。

以上就是两阶段提交的基本过程了，那么按照这个两阶段提交协议，分布式系统的数据一致性问题就能解决么？

3.2 2PC存在的问题

其实，2PC只是通过增加了事务协调者（Coordinator）的角色来通过2个阶段的处理流程来解决分布式系统中一个事务需要跨多个服务的数据一致性问题。

以下几点是XA-两阶段提交协议中会遇到的一些问题：

性能问题：2PC中的所有的参与者节点都为事务阻塞型，当某一个参与者节点出现通信超时，其余参与者都会被动阻塞占用资源不能释放。
协调者单点故障问题：由于严重的依赖协调者，一旦协调者发生故障，而此时参与者还都处于锁定资源的状态，无法完成事务commit操作。虽然协调者出现故障后，会重新选举一个协调者，可无法解决因前一个协调者宕机导致的参与者处于阻塞状态的问题。
网络闪断导致脑裂：第二阶段中协调者向参与者发送commit命令之后，一旦此时发生网络抖动，导致一部分参与者接收到了commit请求并执行，可其他未接到commit请求的参与者无法执行事务提交。进而导致整个分布式系统出现了数据不一致。

4 三阶段提交（3PC）

三阶段提交又称3PC，在2PC的基础上增加了CanCommit阶段，并引入了超时机制。一旦事务参与者迟迟没有收到协调者的Commit请求，就会自动进行本地commit，这样相对有效地解决了协调者单点故障的问题。

4.1 3PC运行原理

4.1.1 CanCommit阶段

协调者向参与者发出CanCommit ，进行事务询问操作，所有参与者都反馈yes后，才能进入下一个阶段。（这一个阶段时不锁表，不像2pc 第一个阶段就开始锁表，3pc的阶段一是为了先排除个别参与者不具备提交事务能力的前提下，而避免锁表。）简单来说就是检查下自身状态的健康性。
有任何一个参与者反馈的结果是No，整个分布式事务就会中断，协调者就会向所有的参与者发送“abort”请求。

4.1.2 PreCommit阶段

在阶段一中，如果所有的参与者都返回Yes的话，那么就会进入PreCommit阶段进行事务预提交。此时分布式事务协调者会向所有的参与者发送PreCommit请求，参与者收到后开始执行事务操作，并将Undo和Redo信息记录到事务日志中。参与者执行完事务操作后（此时属于未提交事务的状态），就会向协调者反馈“Ack”表示已经准备好提交，并等待协调者的下一步指令。
有任何一个参与者反馈的结果是No，或协调者在等待参与者节点反馈的过程中超时（2PC中只有协调者可以超时，参与者没有超时机制）。整个分布式事务就会中断，协调者就会向所有的参与者发送“abort”请求。

4.1.3 DoCommit阶段

在阶段二中如果所有的参与者都可以进行PreCommit提交，那么协调者就会从“预提交状态”->“提交状态”。然后向所有的参与者发送”doCommit”请求，参与者在收到提交请求后，执行事务提交操作，并向协调者反馈“Ack”消息，协调者收到所有参与者的Ack消息后完成事务。
同样，如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送abort请求，从而中断事务。

相比较2PC而言，3PC对于协调者（Coordinator）和参与者（Participant）都设置了超时时间，解决了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

3PC的缺点：

3PC在去除阻塞的同时也引入了新的问题，那就是参与者接收到precommit消息后，如果出现网络分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然出现数据的不一致性。

5 补偿事务（TCC）

TCC与2PC、3PC一样，只是分布式事务的一种实现方案。

5.1 TCC原理：

TCC（Try-Confirm-Cancel）又称补偿事务。其核心思想是：”针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）”。它分为三个操作：

Try阶段：主要是对业务系统做检测及资源预留，比如说冻结库存。
Confirm阶段：确认执行业务操作。
Cancel阶段：取消执行业务操作。

TCC事务的处理流程与2PC两阶段提交类似，不过2PC通常都是在跨库的DB层面，而TCC本质上就是一个应用层面的2PC，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口还必须实现幂等。

TCC的具体原理图如下：

5.2 注意事项：

1.业务操作分两阶段完成：

接入TCC前，业务操作只需要一步就能完成，但是在接入TCC之后，需要考虑如何将其分成2阶段完成，把资源的检查和预留放在一阶段的Try操作中进行，把真正的业务操作的执行放在二阶段的Confirm操作中进行；
TCC服务要保证第一阶段Try操作成功之后，二阶段Confirm操作一定能成功；

2.允许空回滚；

事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因为丢包而导致的网络超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；
TCC服务在未收到Try请求的情况下收到Cancel请求，这种场景被称为空回滚；TCC服务在实现时应当允许空回滚的执行；

3.防悬挂控制；

事务协调器在调用TCC服务的一阶段Try操作时，可能会出现因网络拥堵而导致的超时，此时事务协调器会触发二阶段回滚，调用TCC服务的Cancel操作；在此之后，拥堵在网络上的一阶段Try数据包被TCC服务收到，出现了二阶段Cancel请求比一阶段Try请求先执行的情况；
用户在实现TCC服务时，应当允许空回滚，但是要拒绝执行空回滚之后到来的一阶段Try请求；

4.幂等控制：

无论是网络数据包重传，还是异常事务的补偿执行，都会导致TCC服务的Try、Confirm或者Cancel操作被重复执行；用户在实现TCC服务时，需要考虑幂等控制，即Try、Confirm、Cancel 执行次和执行多次的业务结果是一样的；

5.业务数据可见性控制；

TCC服务的一阶段Try操作会做资源的预留，在二阶段操作执行之前，如果其他事务需要读取被预留的资源数据，那么处于中间状态的业务数据该如何向用户展示，需要业务在实现时考虑清楚；通常的设计原则是“宁可不展示、少展示，也不多展示、错展示”；

6.业务数据并发访问控制；

TCC服务的一阶段Try操作预留资源之后，在二阶段操作执行之前，预留的资源都不会被释放；如果此时其他分布式事务修改这些业务资源，会出现分布式事务的并发问题；
用户在实现TCC服务时，需要考虑业务数据的并发控制，尽量将逻辑锁粒度降到最低，以最大限度的提高分布式事务的并发性；

详解 Seata AT 模式事务隔离级别与全局锁设计

Seata AT 模式是一种非侵入式的分布式事务解决方案，Seata 在内部做了对数据库操作的代理层，我们使用 Seata AT 模式时，实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，比如插入回滚 undo_log 日志，检查全局锁等。

为什么要检查全局锁呢，这是由于 Seata AT 模式的事务隔离是建立在支事务的本地隔离级别基础之上的，在数据库本地隔离级别读已提交或以上的前提下，Seata 设计了由事务协调器维护的全局写排他锁，来保证事务间的写隔离，同时，将全局事务默认定义在读未提交的隔离级别上。

Seata 事务隔离级别解读

在讲 Seata 事务隔离级之前，我们先来回顾一下数据库事务的隔离级别，目前数据库事务的隔离级别一共有 4 种，由低到高分别为：

Read uncommitted：读未提交
Read committed：读已提交
Repeatable read：可重复读
Serializable：序列化

数据库一般默认的隔离级别为读已提交，比如 Oracle，也有一些数据的默认隔离级别为可重复读，比如 Mysql，一般而言，数据库的读已提交能够满足业务绝大部分场景了。

我们知道 Seata 的事务是一个全局事务，它包含了若干个分支本地事务，在全局事务执行过程中（全局事务还没执行完），某个本地事务提交了，如果 Seata 没有采取任务措施，则会导致已提交的本地事务被读取，造成脏读，如果数据在全局事务提交前已提交的本地事务被修改，则会造成脏写。

由此可以看出，传统意义的脏读是读到了未提交的数据，Seata 脏读是读到了全局事务下未提交的数据，全局事务可能包含多个本地事务，某个本地事务提交了不代表全局事务提交了。

在绝大部分应用在读已提交的隔离级别下工作是没有问题的，而实际上，这当中又有绝大多数的应用场景，实际上工作在读未提交的隔离级别下同样没有问题。

在极端场景下，应用如果需要达到全局的读已提交，Seata 也提供了全局锁机制实现全局事务读已提交。但是默认情况下，Seata 的全局事务是工作在读未提交隔离级别的，保证绝大多数场景的高效性。

全局锁实现

AT 模式下，会使用 Seata 内部数据源代理 DataSourceProxy，全局锁的实现就是隐藏在这个代理中。我们分别在执行、提交的过程都做了什么。

1、执行过程

执行过程在 StatementProxy 类，在执行过程中，如果执行 SQL 是 select for update，则会使用 SelectForUpdateExecutor 类，如果执行方法中带有 @GlobalTransactional or @GlobalLock注解，则会检查是否有全局锁，如果当前存在全局锁，则会回滚本地事务，通过 while 循环不断地重新竞争获取本地锁和全局锁。

io.seata.rm.datasource.exec.SelectForUpdateExecutor#doExecute

public T doExecute(Object... args) throws Throwable {
    Connection conn = statementProxy.getConnection();
    // ... ...
    try {
        // ... ...
        while (true) {
            try {
                // ... ...
                if (RootContext.inGlobalTransaction() || RootContext.requireGlobalLock()) {
                    // Do the same thing under either @GlobalTransactional or @GlobalLock, 
                    // that only check the global lock  here.
                    statementProxy.getConnectionProxy().checkLock(lockKeys);
                } else {
                    throw new RuntimeException("Unknown situation!");
                }
                break;
            } catch (LockConflictException lce) {
                if (sp != null) {
                    conn.rollback(sp);
                } else {
                    conn.rollback();
                }
                // trigger retry
                lockRetryController.sleep(lce);
            }
        }
    } finally {
        // ...
    }

2、提交过程

提交过程在 ConnectionProxy#doCommit方法中。

1）如果执行方法中带有@GlobalTransactional注解，则会在注册分支时候获取全局锁：

请求 TC 注册分支

io.seata.rm.datasource.ConnectionProxy#register

private void register() throws TransactionException {
    if (!context.hasUndoLog() || !context.hasLockKey()) {
        return;
    }
    Long branchId = DefaultResourceManager.get().branchRegister(BranchType.AT, getDataSourceProxy().getResourceId(),
                                                                null, context.getXid(), null, context.buildLockKeys());
    context.setBranchId(branchId);
}

TC 注册分支的时候，获取全局锁

io.seata.server.transaction.at.ATCore#branchSessionLock

protected void branchSessionLock(GlobalSession globalSession, BranchSession branchSession) throws TransactionException {
    if (!branchSession.lock()) {
        throw new BranchTransactionException(LockKeyConflict, String
                                             .format("Global lock acquire failed xid = %s branchId = %s", globalSession.getXid(),
                                                     branchSession.getBranchId()));
    }
}

2）如果执行方法中带有@GlobalLock注解，在提交前会查询全局锁是否存在，如果存在则抛异常：

io.seata.rm.datasource.ConnectionProxy#processLocalCommitWithGlobalLocks

private void processLocalCommitWithGlobalLocks() throws SQLException {
    checkLock(context.buildLockKeys());
    try {
        targetConnection.commit();
    } catch (Throwable ex) {
        throw new SQLException(ex);
    }
    context.reset();
}

GlobalLock 注解说明

从执行过程和提交过程可以看出，既然开启全局事务 @GlobalTransactional注解可以在事务提交前，查询全局锁是否存在，那为什么 Seata 还要设计多处一个 @GlobalLock注解呢？

因为并不是所有的数据库操作都需要开启全局事务，而开启全局事务是一个比较重的操作，需要向 TC 发起开启全局事务等 RPC 过程，而@GlobalLock注解只会在执行过程中查询全局锁是否存在，不会去开启全局事务，因此在不需要全局事务，而又需要检查全局锁避免脏读脏写时，使用@GlobalLock注解是一个更加轻量的操作。

Seata分布式事务