BitGarden

Recent Notes

See 555 more →

分布式事务

share40 min read

distribute

什么是事务？

事务从本质上讲就是：逻辑上的一组操作，组成这组操作的各个逻辑单元在不同的服务甚至服务器上，保证它们要成功就都成功，要失败就都失败。

事务的四大特性

提到事务就不得不提事务的四大特性(基本特征) ACID：

  • 原子性(atomicity)：“原子”的本意是“不可再分”，事务的原子性表现为一个事务中涉及到的多个操作在逻辑上缺一不可。事务的原子性要求事务中的所有操作要么都执行，要么都不执行。
  • 一致性(consistency)：“一致”指的是数据的一致，具体是指：所有数据都处于满足业务规则的一致性状态。一致性原则要求：一个事务中不管涉及到多少个操作，都必须保证事务执行之前数据是正确的，事务执行之后数据仍然是正确的。如果一个事务在执行的过程中，其中某一个或某几个操作失败了，则必须将其他所有操作撤销，将数据恢复到事务执行之前的状态，这就是回滚。
  • 隔离性(isolation)：在应用程序实际运行过程中，事务往往是并发执行的，所以很有可能有许多事务同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。隔离性原则要求多个事务在并发执行过程中不会互相干扰。
  • 持久性(durability)：持久性原则要求事务执行完成后，对数据的修改永久的保存下来，不会因各种系统错误或其他意外情况而受到影响。通常情况下，事务对数据的修改应该被写入到持久化存储器中。

隔离级别和常见问题

脏读，不可重复读，幻读

以下几个概念是事务隔离级别要实际解决的问题，所以需要搞清楚都是什么意思。

脏读

1、在事务A执行过程中，事务A对数据资源进行了修改，事务B读取了事务A修改后的数据。

2、由于某些原因，事务A并没有完成提交，发生了RollBack操作，则事务B读取的数据就是脏数据。

这种读取到另一个事务未提交的数据的现象就是脏读(Dirty Read)。
|

不可重复读

事务B读取了两次数据资源，在这两次读取的过程中事务A修改了数据，导致事务B在这两次读取出来的数据不一致。

这种在同一个事务中，前后两次读取的数据不一致的现象就是不可重复读(Nonrepeatable Read)。

|

幻读

事务B前后两次读取同一个范围的数据，在事务B两次读取的过程中事务A新增了数据，导致事务B后一次读取到前一次查询没有看到的行。

幻读和不可重复读有些类似，但是幻读强调的是集合的增减，而不是单条数据的更新。
|

第一类更新丢失

事务A和事务B都对数据进行更新，但是事务A由于某种原因事务回滚了，把已经提交的事务B的更新数据给覆盖了。这种现象就是第一类更新丢失。
|

第二类更新丢失

其实跟第一类更新丢失有点类似，也是两个事务同时对数据进行更新，但是事务A的更新把已提交的事务B的更新数据给覆盖了。这种现象就是第二类更新丢失。
|

事务隔离级别

SQL 标准定义了四种隔离级别，MySQL 全都支持。这四种隔离级别分别是：

  1. 读未提交（READ UNCOMMITTED）
  2. 读提交 （READ COMMITTED）
  3. 可重复读 （REPEATABLE READ）
  4. 串行化 （SERIALIZABLE）

从上往下，隔离强度逐渐增强，性能逐渐变差。采用哪种隔离级别要根据系统需求权衡决定，其中， 可重复读 是 MySQL 的默认级别。

事务隔离其实就是为了解决上面提到的脏读、不可重复读、幻读这几个问题，下面展示了 4 种隔离级别对这三个问题的解决程度。

隔离级别脏读不可重复读幻读
读未提交可能可能可能
读提交不可能可能可能
可重复读不可能不可能可能
串行化不可能不可能不可能

只有串行化的隔离级别解决了全部这 3 个问题，其他的 3 个隔离级别都有缺陷。
但是，对于 mysql 的 innodb 引擎，可重复读已经解决了幻读的问题, 见解决幻读

一探究竟

下面，我们来一一分析这 4 种隔离级别到底是怎么个意思。

如何设置隔离级别

我们可以通过以下语句查看当前数据库的隔离级别，通过下面语句可以看出我使用的 MySQL 的隔离级别是 REPEATABLE-READ，也就是可重复读，这也是 MySQL 的默认级别。

# 查看事务隔离级别 5.7.20 之后
show variables like 'transaction_isolation';
SELECT @@transaction_isolation
 
# 5.7.20 之后
SELECT @@tx_isolation
show variables like 'tx_isolation'
 
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+

稍后，我们要修改数据库的隔离级别，所以先了解一下具体的修改方式。

修改隔离级别的语句是：
set [作用域] transaction isolation level [事务隔离级别]，
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}。

其中作用于可以是 SESSION 或者 GLOBAL，GLOBAL 是全局的，而 SESSION 只针对当前回话窗口。隔离级别是 {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE} 这四种，不区分大小写。

比如下面这个语句的意思是设置全局隔离级别为读提交级别。

mysql> set global transaction isolation level read committed;

MySQL 中执行事务

事务的执行过程如下，以 begin 或者 start transaction 开始，然后执行一系列操作，最后要执行 commit 操作，事务才算结束。当然，如果进行回滚操作(rollback)，事务也会结束。

|

需要注意的是，begin 命令并不代表事务的开始，事务开始于 begin 命令之后的第一条语句执行的时候。例如下面示例中，select * from xxx 才是事务的开始，

begin;
select * from xxx; 
commit; -- 或者 rollback;

另外，通过以下语句可以查询当前有多少事务正在运行。

select * from information_schema.innodb_trx;

好了，重点来了，开始分析这几个隔离级别了。

接下来我会用一张表来做一下验证，表结构简单如下：

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) DEFAULT NULL,
  `age` tinyint(4) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8

初始只有一条记录：

mysql> SELECT * FROM user;
+----+-----------------+------+
| id | name            | age  |
+----+-----------------+------+
|  1 | 古时的风筝        |    1 |
+----+-----------------+------+

读未提交

MySQL 事务隔离其实是依靠锁来实现的，加锁自然会带来性能的损失。而读未提交隔离级别是不加锁的，所以它的性能是最好的，没有加锁、解锁带来的性能开销。但有利就有弊，这基本上就相当于裸奔啊，所以它连脏读的问题都没办法解决。

任何事务对数据的修改都会第一时间暴露给其他事务，即使事务还没有提交。

下面来做个简单实验验证一下，首先设置全局隔离级别为读未提交。

set global transaction isolation level read uncommitted;

设置完成后，只对之后新起的 session 才起作用，对已经启动 session 无效。如果用 shell 客户端那就要重新连接 MySQL，如果用 Navicat 那就要创建新的查询窗口。

启动两个事务，分别为事务A和事务B，在事务A中使用 update 语句，修改 age 的值为10，初始是1 ，在执行完 update 语句之后，在事务B中查询 user 表，会看到 age 的值已经是 10 了，这时候事务A还没有提交，而此时事务B有可能拿着已经修改过的 age=10 去进行其他操作了。在事务B进行操作的过程中，很有可能事务A由于某些原因，进行了事务回滚操作，那其实事务B得到的就是脏数据了，拿着脏数据去进行其他的计算，那结果肯定也是有问题的。

顺着时间轴往表示两事务中操作的执行顺序，重点看图中 age 字段的值。

|

读未提交，其实就是可以读到其他事务未提交的数据，但没有办法保证你读到的数据最终一定是提交后的数据，如果中间发生回滚，那就会出现脏数据问题，读未提交没办法解决脏数据问题。更别提可重复读和幻读了，想都不要想。

读提交

既然读未提交没办法解决脏数据问题，那么就有了读提交。读提交就是一个事务只能读到其他事务已经提交过的数据，也就是其他事务调用 commit 命令之后的数据。那脏数据问题迎刃而解了。

读提交事务隔离级别是大多数流行数据库的默认事务隔离界别，比如 Oracle，但是不是 MySQL 的默认隔离界别。

我们继续来做一下验证，首先把事务隔离级别改为读提交级别。

set global transaction isolation level read committed;

之后需要重新打开新的 session 窗口，也就是新的 shell 窗口才可以。

同样开启事务A和事务B两个事务，在事务A中使用 update 语句将 id=1 的记录行 age 字段改为 10。此时，在事务B中使用 select 语句进行查询，我们发现在事务A提交之前，事务B中查询到的记录 age 一直是1，直到事务A提交，此时在事务B中 select 查询，发现 age 的值已经是 10 了。

这就出现了一个问题，在同一事务中(本例中的事务B)，事务的不同时刻同样的查询条件，查询出来的记录内容是不一样的，事务A的提交影响了事务B的查询结果，这就是不可重复读，也就是读提交隔离级别。

|

每个 select 语句都有自己的一份快照，而不是一个事务一份，所以在不同的时刻，查询出来的数据可能是不一致的。

读提交解决了脏读的问题，但是无法做到可重复读，也没办法解决幻读。

可重复读

可重复是对比不可重复而言的，上面说不可重复读是指同一事物不同时刻读到的数据值可能不一致。而可重复读是指，事务不会读到其他事务对已有数据的修改，及时其他事务已提交，也就是说，事务开始时读到的已有数据是什么，在事务提交前的任意时刻，这些数据的值都是一样的。但是，对于其他事务新插入的数据是可以读到的，这也就引发了幻读问题。

同样的，需改全局隔离级别为可重复读级别。

set global transaction isolation level repeatable read;

在这个隔离级别下，启动两个事务，两个事务同时开启。

首先看一下可重复读的效果，事务A启动后修改了数据，并且在事务B之前提交，事务B在事务开始和事务A提交之后两个时间节点都读取的数据相同，已经可以看出可重复读的效果。

|

可重复读做到了，这只是针对已有行的更改操作有效，但是对于新插入的行记录，就没这么幸运了，幻读就这么产生了。我们看一下这个过程：

事务A开始后，执行 update 操作，将 age = 1 的记录的 name 改为“风筝2号”；

事务B开始后，在事务执行完 update 后，执行 insert 操作，插入记录 age =1，name = 古时的风筝，这和事务A修改的那条记录值相同，然后提交。

事务B提交后，事务A中执行 select，查询 age=1 的数据，这时，会发现多了一行，并且发现还有一条 name = 古时的风筝，age = 1 的记录，这其实就是事务B刚刚插入的，这就是幻读。

|

要说明的是，当你在 MySQL 中测试幻读的时候，并不会出现上图的结果，幻读并没有发生，MySQL 的可重复读隔离级别其实解决了幻读问题，这会在后面的内容说明

串行化

串行化是4种事务隔离级别中隔离效果最好的，解决了脏读、可重复读、幻读的问题，但是效果最差，它将事务的执行变为顺序执行，与其他三个隔离级别相比，它就相当于单线程，后一个事务的执行必须等待前一个事务结束。

MySQL 中是如何实现事务隔离的

首先说读未提交，它是性能最好，也可以说它是最野蛮的方式，因为它压根儿就不加锁，所以根本谈不上什么隔离效果，可以理解为没有隔离。

再来说串行化。读的时候加共享锁，也就是其他事务可以并发读，但是不能写。写的时候加排它锁，其他事务不能并发写也不能并发读。

最后说读提交和可重复读。这两种隔离级别是比较复杂的，既要允许一定的并发，又想要兼顾的解决问题。

实现可重复读

为了解决不可重复读，或者为了实现可重复读，MySQL 采用了 MVVC (多版本并发控制) 的方式。

我们在数据库表中看到的一行记录可能实际上有多个版本，每个版本的记录除了有数据本身外，还要有一个表示版本的字段，记为 row trx_id，而这个字段就是使其产生的事务的 id，事务 ID 记为 transaction id，它在事务开始的时候向事务系统申请，按时间先后顺序递增。

|

按照上面这张图理解，一行记录现在有 3 个版本，每一个版本都记录这使其产生的事务 ID，比如事务A的transaction id 是100，那么版本1的row trx_id 就是 100，同理版本2和版本3。

在上面介绍读提交和可重复读的时候都提到了一个词，叫做快照，学名叫做一致性视图，这也是可重复读和不可重复读的关键，可重复读是在事务开始的时候生成一个当前事务全局性的快照，而读提交则是每次执行语句的时候都重新生成一次快照。

对于一个快照来说，它能够读到那些版本数据，要遵循以下规则：

  1. 当前事务内的更新，可以读到；
  2. 版本未提交，不能读到；
  3. 版本已提交，但是却在快照创建后提交的，不能读到；
  4. 版本已提交，且是在快照创建前提交的，可以读到；

利用上面的规则，再返回去套用到读提交和可重复读的那两张图上就很清晰了。还是要强调，两者主要的区别就是在快照的创建上，可重复读仅在事务开始是创建一次，而读提交每次执行语句的时候都要重新创建一次。

并发写问题

存在这的情况，两个事务，对同一条数据做修改。最后结果应该是哪个事务的结果呢，肯定要是时间靠后的那个对不对。并且更新之前要先读数据，这里所说的读和上面说到的读不一样，更新之前的读叫做“当前读”，总是当前版本的数据，也就是多版本中最新一次提交的那版。

假设事务A执行 update 操作， update 的时候要对所修改的行加行锁，这个行锁会在提交之后才释放。而在事务A提交之前，事务B也想 update 这行数据，于是申请行锁，但是由于已经被事务A占有，事务B是申请不到的，此时，事务B就会一直处于等待状态，直到事务A提交，事务B才能继续执行，如果事务A的时间太长，那么事务B很有可能出现超时异常。如下图所示。

|

加锁的过程要分有索引和无索引两种情况，比如下面这条语句

update user set age=11 where id = 1

id 是这张表的主键，是有索引的情况，那么 MySQL 直接就在索引数中找到了这行数据，然后干净利落的加上行锁就可以了。

而下面这条语句

update user set age=11 where age=10

表中并没有为 age 字段设置索引，所以， MySQL 无法直接定位到这行数据。那怎么办呢，当然也不是加表锁了。MySQL 会为这张表中所有行加行锁，没错，是所有行。但是呢，在加上行锁后，MySQL 会进行一遍过滤，发现不满足的行就释放锁，最终只留下符合条件的行。虽然最终只为符合条件的行加了锁，但是这一锁一释放的过程对性能也是影响极大的。所以，如果是大表的话，建议合理设计索引，如果真的出现这种情况，那很难保证并发度。

解决幻读

上面介绍可重复读的时候，那张图里标示着出现幻读的地方实际上在 MySQL 中并不会出现，MySQL 已经在可重复读隔离级别下解决了幻读的问题。

前面刚说了并发写问题的解决方式就是行锁，而解决幻读用的也是锁，叫做间隙锁，MySQL 把行锁和间隙锁合并在一起，解决了并发写和幻读的问题，这个锁叫做 Next-Key 锁。

假设现在表中有两条记录，并且 age 字段已经添加了索引，两条记录 age 的值分别为 10 和 30。

|

此时，在数据库中会为索引维护一套B+树，用来快速定位行记录。B+索引树是有序的，所以会把这张表的索引分割成几个区间。

|

如图所示，分成了3 个区间，(负无穷,10]、(10,30]、(30,正无穷]，在这3个区间是可以加间隙锁的。

之后，我用下面的两个事务演示一下加锁过程。

|

在事务A提交之前，事务B的插入操作只能等待，这就是 间隙锁 起得作用。当事务A执行 update user set name='风筝2号’ where age = 10; 的时候，由于条件 where age = 10 ，数据库不仅在 age =10 的行上添加了行锁，而且在这条记录的两边，也就是(负无穷,10]、(10,30]这两个区间加了间隙锁，从而导致事务B插入操作无法完成，只能等待事务A提交。不仅插入 age = 10 的记录需要等待事务A提交，age<10、10<age<30 的记录页无法完成，而大于等于30的记录则不受影响，这足以解决幻读问题了。

这是有索引的情况，如果 age 不是索引列，那么数据库会为整个表加上间隙锁。所以，如果是没有索引的话，不管 age 是否大于等于30，都要等待事务A提交才可以成功插入。

总结

MySQL 的 InnoDB 引擎才支持事务，其中可重复读是默认的隔离级别。

读未提交和串行化基本上是不需要考虑的隔离级别，前者不加锁限制，后者相当于单线程执行，效率太差。

读提交解决了脏读问题，行锁解决了并发更新的问题。并且 MySQL 在可重复读级别解决了幻读问题，是通过行锁和间隙锁的组合 Next-Key 锁实现的。

Link to original

Spring传播行为

Spring传播行为介绍
REQUIRED支持当前事务，如果不存在，就新建一个
SUPPORTS支持当前事务，如果不存在，就不使用事务
MANDATORY支持当前事务，如果不存在，抛出异常
REQUIRES_NEW如果有事务存在，挂起当前事务，创建一个新的事务
NOT_SUPPORTED以非事务方式运行，如果有事务存在，挂起当前事务
NEVER以非事务方式运行，如果有事务存在，抛出异常
NESTED如果当前事务存在，则嵌套事务执行（嵌套式事务）

分布式事务

背景

1.1 分布式架构演进之 - 数据库的水平拆分

如下图所示，分库分表之后，原来在一个数据库上就能完成的写操作，可能就会跨多个数据库，这就产生了跨数据库事务问题。

500

1.2 分布式架构演进之 - 业务服务化拆分

将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。

500

业务系统按照服务拆分之后，一个完整的业务往往需要调用多个服务，如何保证多个服务间的数据一致性成为一个难题。

总结

不同的服务，不同数据库
相同的服务，不同数据库
不同的服务，相同数据库

CAP 理论

CAP：

分布式存储系统的CAP原理（分布式系统的三个指标）：

Consistency（一致性） ：在分布式系统中的所有数据备份，在同一时刻是否同样的值。
对于数据分布在不同节点上的数据来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。

  • 对于一致性，可以分为从客户端和服务端两个不同的视角。
    • 客户端
    • 从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
    • 服务端
    • 从服务端来看，则是更新如何分布到整个系统，以保证数据最终一致。
  • 对于一致性，可以分为强/弱/最终一致性三类
    • 从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
    • 强一致性
      • 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。
    • 弱一致性
      • 如果能容忍后续的部分或者全部访问不到，则是弱一致性。
    • 最终一致性
      • 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

Availability（可用性） ：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（要求数据需要备份）
Partition tolerance（分区容忍性） ：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。

权衡

CAP 理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们无法避免的。所以我们只能在一致性和可用性之间进行权衡，没有系统能同时保证这三点。要么选择 CP、要么选择 AP。

证明

495

假设在 N1和 N2之间网络断开的时候，有用户向 N1发送数据更新请求，那 N1中的数据 V0将被更新为 V1，由于网络是断开的，所以分布式系统同步操作 M，所以 N2中的数据依旧是 V0；这个时候，有用户向 N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据 V1，怎么办呢？

有二种选择，第一，牺牲数据一致性，响应旧的数据V0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作M完成之后，再给用户响应最新的数据V1。

这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。

BASE 理论

BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来看看 BASE 中的三要素：

Basically Available（基本可用）
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。 电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
Soft state（软状态）
软状态是指允许系统存在中间状态， 而该中间状态不会影响系统整体可用性 。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
Eventually consistent（最终一致性）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
BASE 模型是传统 ACID 模型的反面，不同于 ACID，BASE 强调牺牲高一致性，从而获得可用性，数据允许在一段时间内的不一致， 只要保证最终一致就可以了。

解决方案

分布式事务模型

解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。这里的子系统事务，称为 分支事务 ；有关联的各个分支事务在一起称为 全局事务

505

  • 全局事务：整个分布式事务
  • 分支事务：分布式事务中包含的每个子系统的事务

方案

  • 两阶段提交（2PC）
    • XA
    • AT
    • 2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P 是指准备阶段，C 是指提交阶段。
  • 三阶段提交 TCC （Try, Confirm, Cancel）
  • 消息队列
    • saga

Seata 分布式事务架构

  • TC(Transaction Coordinator)-事务协调者： 维护全局和分支事务的状态，协调全局事务提交或回滚。
  • TM(Transaction Manager)-事务管理器： 定义全局事务的范围、开始全局事务、提交或回滚全局事务。
  • RM(Resource Manager)-资源管理器： 管理分支事务处理的资源，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

|

在 Seata 中，分布式事务的执行流程：

  • TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
  • 按业务场景， 编排 数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
  • TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
  • TC 汇总事务信息，决定分布式事务是提交还是回滚；
  • TC 通知所有 RM 提交/回滚 资源，事务二阶段结束；

Seata 提供了 4 中不同的分布式事务解决方案：

  • XA 模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
  • TCC 模式：最终一致的分阶段事务模式，有业务侵入
  • AT 模式：最终一致的分阶段事务模式，无业务侵入，也是 Seata 的默认模式
  • SAGA 模式：长事务模式，有业务侵入

XA 模式原理

XA 规范是 X/Open 组织定义的分布式事务处理(DTP，Distributed Transaction Processing)标准，XA 规范描述了全局的 TM 与局部的 RM 之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。
标准的 XA 模式为两阶段提交：

  • 第一阶段由事务协调者向 RM(XA 模式下一般由数据库实现)发起事务准备请求，RM 执行完毕之后，并不直接提交事务，而是将执行的结果告知事务协调者。
  • 第二阶段由事务协调者判断 RM 的返回结果，如果分支事务都成功了，向 RM 发起提交请求，RM 执行事务提交并返回已提交请求

具体过程如下图所示

|

但是，如果在事务执行过程中有一个失败了，事务协调者则会回滚所有已执行事务

|

Seata 在实现 XA 模式时进行了一定的调整，但大体上相似：
RM 一阶段工作：

  1. 注册分支事务到 TC
  2. 执行分支业务 SQL 但不提交
  3. 报告执行状态到 TC

TC 二阶段工作：

  • TC 检测各分支事务执行状态
  • 如果都成功，通知所有 RM 提交事务
  • 如果有失败，通知所有 RM 回滚事务

RM 二阶段工作：

  • 接受 TC 指令，提交或回滚事务

|

XA 模式总结

优点：

  • 事务强一致性，满足 ACID 原则
  • 常用数据库都支持，实现简单，没有代码侵入

缺点：

  • 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，所以性能较差
  • 依赖关系型数据库实现事务

AT 模式原理

AT 模式同样是分阶段提交的事务模型，不过缺弥补了 XA 模型中资源锁定周期过长的缺陷。

|

AT 模式在执行完 sql 之后会 直接提交事务，而不是进行等待 ，在执行的同时 RM 拦截本次执行，记录更新前后的快照到数据库的 undo_log 中。
与 XA 的不同之处在于

阶段一 RM 的工作：

  • 注册分支事务
  • 记录 undo-log(数据快照)
    • 也叫 before image
  • 执行业务 sql 并 提交
  • 报告事务状态

阶段二提交时 RM 的工作：

  • 删除 undo-log 即可

阶段二回滚时 RM 的工作：

  • 根据 undo-log 回复数据到更新前

具体案例：例如，一个分支业务的 SQL 是这样的：update tb_account set money = money - 10 where id = 1

|

如果这条 sql 执行成功，那么 money 字段自然是 90，如果执行失败，则根据数据快照恢复数据。

AT 模式总结

与 XA 模式最大的区别是：

  • XA 模式一阶段不提交事务，锁定资源；AT 模式一阶段直接提交，不锁定资源。
  • XA 模式依赖数据库机制实现回滚；AT 模式利用数据快照实现数据回滚。
  • XA 模式强一致；AT 模式最终一致

优点：

  • 一阶段完成直接提交事务，释放数据库资源，性能比较好
  • 利用全局锁实现读写隔离
  • 没有代码侵入，框架自动完成回滚和提交

缺点：

  • 两阶段之间属于软状态，属于最终一致
  • 框架的快照功能会影响性能，但比 XA 模式要好很多

TCC 模式原理

TCC 模式与 AT 模式非常相似，每阶段都是独立事务，不同的是 TCC 通过人工编码来实现数据恢复。需要实现三个方法：

  • Try：资源的检测和预留；
  • Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
  • Cancel：预留资源释放，可以理解为 Try 的反向操作。

1 TCC 设计 - 业务模型分 2 阶段设计：

举例，一个扣减用户余额的业务。假设账户 A 原来余额是 100，需要余额扣减 30元。

  • 阶段一(Try): 检查余额是否充足，如果充足则冻结金额增加 30 元，可用余额扣除 30

|

  • 阶段二：假如要提交（Confirm），则冻结金额扣减 30

|

  • 阶段三：如果要回滚（Cancel），则冻结金额扣减 30，可用余额增加 30

|

Try 方法作为一阶段准备方法，需要做资源的检查和预留。在扣钱场景下，Try 要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结 A 账户的转账资金。Try 方法执行之后，账号 A 余额虽然还是 100，但是其中 30 元已经被冻结了，不能被其他事务使用。

二阶段 Confirm 方法执行真正的扣钱操作。Confirm 会使用 Try 阶段冻结的资金，执行账号扣款。Confirm 方法执行之后，账号 A 在一阶段中冻结的 30 元已经被扣除，账号 A 余额变成 70 元 。

如果二阶段是回滚的话，就需要在 Cancel 方法内释放一阶段 Try 冻结的 30 元，使账号 A 的回到初始状态，100 元全部可用。

用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。

2 TCC 设计 - 允许空回滚：

16_51_44__08_13_2019.jpg

Cancel 接口设计时需要允许空回滚。在 Try 接口因为丢包时没有收到，事务管理器会触发回滚，这时会触发 Cancel 接口，这时 Cancel 执行时发现没有对应的事务 xid 或主键时，需要返回回滚成功。让事务服务管理器认为已回滚，否则会不断重试，而 Cancel 又没有对应的业务数据可以进行回滚。

3 TCC 设计 - 防悬挂控制：

16_51_56__08_13_2019.jpg

悬挂的意思是：Cancel 比 Try 接口先执行，出现的原因是 Try 由于网络拥堵而超时，事务管理器生成回滚，触发 Cancel 接口，而最终又收到了 Try 接口调用，但是 Cancel 比 Try 先到。按照前面允许空回滚的逻辑，回滚会返回成功，事务管理器认为事务已回滚成功，则此时的 Try 接口不应该执行，否则会产生数据不一致，所以我们在 Cancel 空回滚返回成功之前先记录该条事务 xid 或业务主键，标识这条记录已经回滚过，Try 接口先检查这条事务xid或业务主键如果已经标记为回滚成功过，则不执行 Try 的业务操作。

4 TCC 设计 - 幂等控制：

16_52_07__08_13_2019.jpg

幂等性的意思是：对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。因为网络抖动或拥堵可能会超时，事务管理器会对资源进行重试操作，所以很可能一个业务操作会被重复调用，为了不因为重复调用而多次占用资源，需要对服务设计时进行幂等控制，通常我们可以用事务 xid 或业务主键判重来控制。

TCC 工作模型图：

|

TCC 模式总结

TCC 模式的每个阶段是做什么的？

  • Try：资源检查和预留
  • Confirm：业务执行和提交
  • Cancel：预留资源的释放

TCC 的优点是什么？

  • 一阶段完成直接提交事务，释放数据库资源，性能好
  • 相比 AT 模型，无需生成快照，无需使用全局锁，性能最强
  • 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC 的缺点是什么？

  • 有代码侵入，需要人为编写 try、Confirm 和 Cancel 接口
  • 软状态，事务是最终一致
  • 需要考虑 Confirm 和 Cancel 的失败情况，做好幂等处理

SAGA 模式

Saga 模式是 SEATA 提供的长事务解决方案。也分为两个阶段：

  • 一阶段：直接提交本地事务(TCC 是预留)
  • 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

如图所示，SAGA 模式下，事务一旦有一个出现问题，则反向按照事务调用顺序进行补偿，从而保证一致性

|

1 Saga 模式使用场景

16_44_58__08_13_2019.jpg

Saga 模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。

事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，可以使用 Saga 模式。

Saga模式的优势是：

  • 一阶段提交本地数据库事务，无锁，高性能；
  • 参与者可以采用事务驱动异步执行，高吞吐；
  • 补偿服务即正向服务的“反向”，易于理解，易于实现；

缺点：Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。后续会讲到对于缺乏隔离性的应对措施。

2 基于状态机引擎的 Saga 实现

17_13_19__08_13_2019.jpg

目前 Saga 的实现一般有两种，一种是通过事件驱动架构实现，一种是基于注解加拦截器拦截业务的正向服务实现。Seata 目前是采用事件驱动的机制来实现的，Seata 实现了一个状态机，可以编排服务的调用流程及正向服务的补偿服务，生成一个 json 文件定义的状态图，状态机引擎驱动到这个图的运行，当发生异常的时候状态机触发回滚，逐个执行补偿服务。当然在什么情况下触发回滚用户是可以自定义决定的。该状态机可以实现服务编排的需求，它支持单项选择、并发、异步、子状态机调用、参数转换、参数映射、服务执行状态判断、异常捕获等功能。

3 状态机引擎原理

16_45_32__08_13_2019.jpg

该状态机引擎的基本原理是，它基于事件驱动架构，每个步骤都是异步执行的，步骤与步骤之间通过事件队列流转，
极大的提高系统吞吐量。每个步骤执行时会记录事务日志，用于出现异常时回滚时使用，事务日志会记录在与业务表所在的数据库内，提高性能。

4 状态机引擎设计

16_45_46__08_13_2019.jpg

该状态机引擎分成了三层架构的设计，最底层是“事件驱动”层，实现了 EventBus 和消费事件的线程池，是一个 Pub-Sub 的架构。第二层是“流程控制器”层，它实现了一个极简的流程引擎框架，它驱动一个“空”的流程执行，“空”的意思是指它不关心流程节点做什么事情，它只执行每个节点的 process 方法，然后执行 route 方法流转到下一个节点。这是一个通用框架，基于这两层，开发者可以实现任何流程引擎。最上层是“状态机引擎”层，它实现了每种状态节点的“行为”及“路由”逻辑代码，提供 API 和状态图仓库，同时还有一些其它组件，比如表达式语言、逻辑计算器、流水生成器、拦截器、配置管理、事务日志记录等。

5 Saga 服务设计经验

和TCC类似，Saga的正向服务与反向服务也需求遵循以下设计原则：

1）Saga 服务设计 - 允许空补偿

16_52_22__08_13_2019.jpg

2）Saga 服务设计 - 防悬挂控制

16_52_52__08_13_2019.jpg

3）Saga 服务设计 - 幂等控制

3 分布式事务 Seata 三种模式详解-屹远-31.jpg

4）Saga 设计 - 自定义事务恢复策略

16_53_07__08_13_2019.jpg

前面讲到 Saga 模式不保证事务的隔离性，在极端情况下可能出现脏写。比如在分布式事务未提交的情况下，前一个服务的数据被修改了，而后面的服务发生了异常需要进行回滚，可能由于前面服务的数据被修改后无法进行补偿操作。这时的一种处理办法可以是“重试”继续往前完成这个分布式事务。由于整个业务流程是由状态机编排的，即使是事后恢复也可以继续往前重试。所以用户可以根据业务特点配置该流程的事务处理策略是优先“回滚”还是“重试”，当事务超时的时候，Server 端会根据这个策略不断进行重试。

由于 Saga 不保证隔离性，所以我们在业务设计的时候需要做到“宁可长款，不可短款”的原则，长款是指在出现差错的时候站在我方的角度钱多了的情况，钱少了则是短款，因为如果长款可以给客户退款，而短款则可能钱追不回来了，也就是说在业务设计的时候，一定是先扣客户帐再入帐，如果因为隔离性问题造成覆盖更新，也不会出现钱少了的情况。

6 基于注解和拦截器的 Saga 实现

17_13_37__08_13_2019.jpg

还有一种 Saga 的实现是基于注解+拦截器的实现，Seata 目前没有实现，可以看上面的伪代码来理解一下，one 方法上定义了 @SagaCompensable 的注解，用于定义 one 方法的补偿方法是 compensateOne 方法。然后在业务流程代码 processA 方法上定义 @SagaTransactional 注解，启动 Saga 分布式事务，通过拦截器拦截每个正向方法当出现异常的时候触发回滚操作，调用正向方法的补偿方法。

7 两种 Saga 实现优劣对比

两种 Saga 的实现各有又缺点，下面表格是一个对比：

17_13_49__08_13_2019.jpg

状态机引擎的最大优势是可以通过事件驱动的方法异步执行提高系统吞吐，可以实现服务编排需求，在 Saga 模式缺乏隔离性的情况下，可以多一种“向前重试”的事情恢复策略。注解加拦截器的的最大优势是，开发简单、学习成本低。

8 SAGA 模式总结

Saga 模式优点：

  • 事务参与者可以基于事件驱动实现异步调用，吞吐高
  • 一阶段直接提交事务，无锁，性能好
  • 不用编写 TCC 中的三个阶段，实现简单

缺点：

  • 软状态持续时间不确定，时效性差
  • 没有锁，没有事务隔离，会有脏写

四种模式对比

-XAATTCCSAGA
一致性强一致最终一致最终一致最终一致
隔离性完全隔离基于全局锁隔离基于资源预留隔离无隔离
代码侵入无无有，需要编写 3 个接口有，需要编写状态机和补偿业务
性能差好非常好非常好
场景对一致性、隔离性有高要求的业务基于关系型数据库的大多数分布式事务场景都可以对性能要求较高的事务；有非关系型数据库要参与的事务业务流程长、业务流程多；参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

两阶段提交的缺点

1）同步阻塞问题。

执行过程中，所有参与节点都是事务阻塞型的（在预提交后，必须等待提交或回滚，注意：通常所谓的二阶段提交，没有超时故障处理的概念，所以说会一直等待）。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

2）单点故障。

由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。（同样，前提是没有引入超时处理机制）

尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。

3）数据不一致。

在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。（前提是，二阶段提交没有引入重试机制）

引入超时和重试

上述二阶段提交的缺点，都是因为没有 超时机制 和 重试机制 产生的。如果引入超时机制和重试机制，效果又会如何呢？

能否解决“同步阻塞问题”？？：预提交之后，如果1分钟没有收到消息，参与者该怎么办？只能选择提交或回滚，但是无论选择哪一项，都可能造成和其他节点数据的不一致。但是引入重试机制之后，基本上能保证所以节点收到消息。

能否解决“单点故障问题”？？：若协调者在预提交之后挂掉，所有参与者都懵逼了，他们只能默认选择提交或回滚，问题同上，而且协调者都挂了，没办法重试，只能重新选举协调者，但是新的协调者如何知道 旧协调者的决议？除非旧协调者把每次决议写到数据库中？否则，新协调者无法继续处理之前的事务。

能否解决“数据不一致问题”？？：上面已经说了，数据可能不一致。而且在回滚阶段，也可能不一致。

总结

综上，二阶段提交，即使引入 超时机制和 重试机制，依然无法解决 同步阻塞、单点故障和数据不一致的问题。

有人举了一个形象的例子：

假设有一个决策小组由一个主持人负责与多位组员以电话联络方式协调是否通过一个提案，对两阶段提交来说，主持人收到一个提案请求，打电话跟每个组员询问是否通过并统计回复，然后将最后决定打电话通知各组员。

要是主持人在跟第一位组员通完电话后失忆，而第一位组员在得知结果并执行后老人痴呆，那么即使重新选出主持人，也没人知道最后的提案决定是什么，也许是通过，也许是驳回，不管大家选择哪一种决定，都有可能与第一位组员已执行过的真实决定不一致，老板就会不开心认为决策小组沟通有问题而解雇。

三阶段提交的问题

三阶段提交并非足够完美（但我觉得已经很好了），下面分析它存在的问题（网络分区问题）：

如果有部分参与者 与 协调者 失联了，那该怎么办？首先，对于第二阶段的失联，协调者会努力重试，超过重试时间后，它将发起回滚。所以，失联的参与者，如果已经执行了预提交，且在重试时间之后仍未联系到协调者，它就可以执行回滚。

其次 ，对于第三阶段的失联，同理，协调者会努力重试，超过重试时间后，它将发起回滚。失联的参与者，如果在重试时间之后仍未联系到协调者，它就可以执行回滚。

基于重试超时时间的回滚方案，可以让三阶段提交方案的一致性加强，但是重试总时间怎么能控制精确呢？（每个节点都需要一个计时器？）。所以，这个方案一致性还可以，但是需要改进，它仍然没有彻底解决分布式的一致性问题。

参考

分布式事务XA、AT、TCC、SAGA - benym
Java分布式事务及seata框架的使用 - 知乎
分布式事务 Seata 及其三种模式详解

Graph View

Backlinks