第二章 分布式事务实战笔记

一、事务基本概念

1、什么是事务？ 

事务是恢复和并发控制的基本单位，事务有四个特性（ACID），原子性（Atomicity），一致性（Consistency），隔离性（Isolation），持久性（Durability）。

2、事务经典场景 

假设这样一个场景： A给B转账100，流程步骤如下：

第一步：A减100，第二步：B多100。

如果第一步骤执行后，系统崩溃掉了，会怎么样呢？

问题：A被减掉了100，但B的钱未能加100. 此时，A + B的金钱总额凭空少了100，数据不一致了。

解决思路？

我们希望步骤1和步骤2能够绑定在一起执行，不可分；并且在步骤1和步骤 2执行的过程中，尽量规避中间状态，即谓事务。事务在解决上述问题中，提出了以下四种特性ACID。

1、原子性

原子性就是不可拆分的特性，要么全部成功然后提交(commit)，要么全部失败然后回滚（rollback）。若开启事务，在上述场景就不会出现A少100成功，B多100失败这种情况。

MySQL通过Redo Log重做日志实现了原子性，在将执行SQL语句时，会先写入redo log buffer，再执行 SQL 语句，若 SQL 语句执行出错就会根据 redo log buffer 中的记录来执行回滚操作，由此拥有原子性。

2、一致性

一致性指事务将数据库从一种状态转变为下一种一致的状态。比如有一个字段name有唯一索引约束，那么在事务前后都不能有重复的name出现违反唯一索引约束，否则回滚。

在上述场景中即金钱总数总是200，不能凭空增加减少，MySQL通过undo Log实现一致性，执行SQL语句时，会先写入undo log再写入redo log buffer。undo是逻辑日志，会根据之前的SQL语句进行相应回滚，比如之前是insert那么回滚时会执行一个delete，一个update会执行一个相反的update。并且除了回滚，undo log还有一个作用是MVCC，当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可通过undo读取之前的行版本信息，实现非锁定读取。并且undo log也会产生redo log，因为undo log也需要持久性的保护。

3、隔离性

首先介绍如果没有隔离性会发生的4种情况：

3.1、丢失更新

A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来，MySQL通过三级封锁协议的第一级解决了丢失更新，事务T要修改数据A时必须加X锁，直到T结束才释放锁。

3.2、脏读

脏读主要是读取到了其他事务的数据，而其他事务随后发生回滚。MySQL通过三级封锁 协议的第二级解决了脏读，在一级的基础上，要求读取数据A时必须加S锁，读取完马上释放S锁。

3.3、不可重复读

不可重复读是读取到数据后，随后其他事务对数据发生了修改，无法再次读取。MySQL通过三级封锁协议的第三级解决了不可重复读。在二级的基础上，要求读取数据A时必须加S锁，直到事务结束了才能释放S锁。

3.4、幻读

幻读是读取到数据后，随后其他事务对数据发生了新增，无法再次读取。在InnoDB引擎Repeatable Read的隔离级别下，MySQL通过Next-Key Lock以及MVCC解决了幻读，事务中分为当前读以及快照读。

4、持久性

一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。具体实现原理就是在事务commit之前会将，redo log buffer中的数据持久化到硬盘中的redo log file，这样在commit的时候，硬盘中已经有了我们修改或新增的数据，由此做到持久化。

二、事务原理与锁

1、锁的问题场景

多对一问题，多个操作者同时操作一个资源，而资源的状态变化是非原子的（有中间态），哄抢会导致资源状态混乱。

 

2、事务的问题场景

一对多的问题，一个操作者需要绑定操作一系列资源（比如多条sql），若任何一条操作失败，都会导致整个操作失去意义。

 

3、事务的实现（了解即可）

3.1、redo log

redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log），前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中。

PS：mysql为了提升性能不会把每次的数据修改都实时同步到磁盘，而是会先存到buffer Pool(缓冲池)里头，把这个当作缓存来用，然后使用后台线程去做缓冲池和磁盘之间的同步。

redo log主要用来恢复数据，用于保障，已提交事务的持久化特性（宕机redo log的信息是全的）。

3.2、undo log

undo log叫做回滚日志，用于记录数据被修改前的信息。他正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息。undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。

PS：mysql每次写入数据或者修改数据之前都会把修改前的信息记录到undo log。

undo log是用来回滚数据，用于保障未提交事务的原子性。

3.3、mysql锁技术

当多个请求同时来临时，mysql要控制读读可并行，而写读、写写不能并行，读写锁的兼容性如下：

	读锁	写锁
读锁	可并行	不可并行
写锁	不可并行	不可并行

3.4. MVCC基础

MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。InnoDB的MVCC是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间，当然存储的并不是实际的时间值，而是系统版本号。他的主要实现思想是通过数据多版本来做到读写分离，从而实现不加锁读进而做到读写并行。

• 事务的原子性是通过undo log来实现的。
• 事务的持久性是通过redo log来实现的。
• 事务的隔离性是通过 (读写锁+MVCC)来实现的。
• 而事务的一致性是通过原子性，持久性，隔离性来实现的！

4、事务的操作过程

4.1、编程式事务：

使用TransactionTemplate或者直接使用底层的TransactionManager来操作事务commit或者rollback。

4.2、声明式事务：

建立在AOP基础上，通过对方法前后进行拦截，加入编程式事务里的流程控制逻辑。使用的时候只需要在方法前面加上@Transactional注解。

三、分布式事务

1、分布式事务概念

1.1、分布式事务产生的原因

随着互联网高速发展，事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用。在这种环境中，我们之前说过数据库的ACID四大特性，已经无法满足我们分布式事务。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

 

1.2、CAP理论

CAP定理，又被叫作布鲁尔定理。CAP指的是：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

CAP定律说的是，在一个分布式系统中，最多只能满足C、A、P中的两个，不可能三个同时满足。而在分布式系统中，网络无法100%可靠，分区其实是一个必然现象。如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。而且，显然任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。

1.3、BASE理论

往往在分布式系统中无法实现完全一致性，于是有了BASE理论，它是对CAP定律的进一步扩充。

BASE指的是：

Basically Available基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

Soft state软状态：允许系统中存在中间状态，这个状态不影响系统可用性。

Eventually consistent最终一致性：经过一段时间后，所有节点数据都将会达到一致。

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，BASE理论核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

BASE和ACID是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

2、基于XA协议的两阶段提交

X/Open组织提出了分布式事务的规范----- XA协议，XA协议包含两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，目前主流的关系型数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA的核心，便是全局事务，通过XA二阶段提交协议，与各分布式数据交互，分准备与提交两个阶段。

逻辑流程如下图：

 

2.1、在XA协议中事务分为两阶段：

• 事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。
• 事务协调器要求每个数据库提交数据，或者回滚数据。

2.2、优点：

尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持。

2.3、缺点：

• 单点问题：事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。·
• 同步阻塞：在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。 ·
• 数据不一致：两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能。 比如在第二阶段中，假设协调者发出了事务Commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了Commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

3、3PC事务

3PC全称three phase commit，是2PC的改进版，其将2PC的“提交事务请求”过程一分为二。

如下图所示：

 

3.1、第一个阶段CanCommit：

1）事务询问：协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2）各参与者向协调者反馈事务询问的响应：参与者接收来自协调者的canCommit请求，如果参与者认为自己可以顺利执行事务，就返回Yes，否则反馈No响应。这一阶段主要是确定分布式事务的参与者是否具备了完成commit的条件，并不会执行事务操作。

3.2、第二阶段precommit：

协调者在得到所有参与者的响应之后，会根据结果执行2种操作：执行事务预提交，或者中断事务。

1）执行事务预提交分为3 个步骤：

• 发送预提交请求：协调者向所有参与者节点发出preCommit的请求，并进入prepared状态。
• 事务预提交：参与者受到preCommit请求后，会执行事务操作，对应2PC中的“执行事务”，也会 Undo和Redo信息记录到事务日志中。
• 各参与者向协调者反馈事务执行的结果：如果参与者成功执行了事务，就反馈Ack响应，同时等待指令：提交commit或终止abort。

2）中断事务也分为2个步骤：

• 发送中断请求：协调者向所有参与者节点发出abort请求。
• 中断事务：参与者如果收到abort请求或者超时了，都会中断事务。

3.3、第三阶段doCommit

1）执行提交

• 发送提交请求：进入这一阶段，如果协调者正常工作，并且接收到了协调者的Ack响应，那么协调者将从“预提交”状态变为“提交”状态，并向所有的参与者发送doCommit请求。
• 事务提交：参与者收到doCommit请求后，会正式执行事务提交操作，并在完成之后释放在整个事务执行期间占用的事务资源。
• 反馈事务提交结果：参与者完成事务提交后，向协调者发送Ack消息。
• 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务。

2）中断事务（假设有任何参与者反馈no响应，或者超时了，就中断事务）。 

• 发送中断请求：协调者向所有的参与者节点发送abort请求。
• 事务回滚：参与者接收到abort请求后，会利用其在二阶段记录的undo信息来执行事务回滚操作，并在完成回滚之后释放整个事务执行期间占用的资源。
• 反馈事务回滚结果：参与者在完成事务回滚之后，想协调者发送Ack消息。
• 中断事务：协调者接收到所有的Ack消息后，中断事务。

3.4、3PC与2pc的区别

注意：在阶段三，可能会出现2种故障：协调者出现问题/协调者和参与者之间的网络故障。

一段出现了任何一种情况，最终都会导致参与者无法收到doCommit请求或者abort请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交。

优点：相比较2PC，最大的优点是减少了参与者的阻塞范围（第一个阶段是不阻塞的），并且能够在单点故障后继续达成一致（2PC在提交阶段会出现此问题，而3PC会根据协调者的状态进行回滚或者提交）。

缺点：如果参与者收到了preCommit消息后，出现了网络分区，那么参与者等待超时后，都会进行事务的提交，这必然会出现事务不一致的问题。

4、TCC方案

TCC其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其业务逻辑对应的确认和补偿（撤销）操作。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。

 

优点：跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些。

缺点：TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，而且补偿的时候也有可能失败，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

5、MQ事务消息

目前，仅阿里云的RocketMQ支持事务消息，帮助用户实现类似X/Open XA的分布事务功能，通过MQ事务消息能达到分布式事务的最终一致。

 

流程说明：

1）发送方向MQ服务端发送消息。

2）MQ Server将消息持久化成功之后，向发送方ACK确认消息已经发送成功，此时消息为半消息

3）发送方开始执行本地事务逻辑。

4）发送方根据本地事务执行结果向MQ Server提交二次确认（Commit或是Rollback），MQ Server收到Commit状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server收到Rollback状态则删除半消息，订阅方将不会接受该消息。

5）在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达MQ Server，经过固定时间后MQ Server将对该消息发起消息回查。

6）发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。

7）发送方根据检查得到的本地事务的最终状态再次提交二次确认，MQ Server仍按照步骤4对半消息进行操作。

其中，事务消息发送对应步骤1、2、3、4，事务消息回查对应步骤5、6、7。

6、Lcn事务

6.1背景

LCN名称是由早期版本的LCN框架命名，在设计框架之初的1.0~ 2.0的版本时框架设计的步骤是如下，各取其首字母得来的LCN命名。

• 锁定事务单元（lock）
• 确认事务模块状态(confirm)
• 通知事务(notify)

6.2 框架定位

LCN并不生产事务，LCN只是本地事务的协调工。

TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。

6.3 事务控制原理

TX-LCN由两大模块组成：TxClient、TxManager

TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制方。事务发起方或者参与反都由TxClient 端来控制。

原理图：

 

1）创建事务组

是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。

2）加入事务组

添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。

3）通知事务组

是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager，TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。

7、Seata事务

7.1、背景

Seata(Simple Extensible Autonomous Transaction Architecture)是阿里巴巴开源的分布式事务中间件，以高效并且对业务0侵入的方式，解决微服务场景下面临的分布式事务问题。

7.2、设计思想

seata的AT模式，采用的是大量运用在数据库软件的Write Ahead Log思想，即把事务的信息以事务日志的方式记录下来。

这种处理方式，实际上是对传统两阶段提交的一种改进和优化。主要有几个关键点：

1）传统两阶段提交协议是阻塞协议，性能差。

2）传统两阶段提交协议高可用性不好。

3）传统两阶段提交协议的全局事务隔离机制不支持。

4）根据八二原则，80%的涉及到全局事务的业务是能正常完成并提交的。

因此，在AT模式下，seata采取的做法是，一个事务分支的数据库操作执行完后，马上进行本地事务的提交，从而释放相关的数据库资源。

 

• 分支事务中数据的本地锁由本地事务管理，在分支事务Phase1结束时释放。
• 同时，随着本地事务结束，连接也得以释放。
• 分支事务中数据的全局锁在事务协调器侧管理，在决议Phase2全局提交时，全局锁马上可以释放。只有在决议全局回滚的情况下，全局锁才被持有至分支的Phase2结束。

7.3、本地事务执行流程

在进行本地提交的前提是，seata会解析SQL，获取数据库表的元数据，根据SQL类型，选择性地生成数据的前置镜像和后置镜像，保存在undo_log表中，并且要求与保存undo_log与业务SQL在同一个本地事务内。这就保证了：

1）如果一个本地事务被提交，那么必定对应着相应的undo_log。

2）如果保存undo_log保存失败，那么业务SQL也会失败。

 

7.4 全局事务提交流程

因为每个分支事务的本地事务都已经被提交，所以如果全局事务能够顺利进行到“提交“这一阶段，那么意味着所有事务分支的本地事务都已经被提交了，数据的一致性已经得到了保证。这个时候全局事务的提交就变得十分轻量级，就是把undo_log对应的记录删掉即可，即使是当时删除失败了，也已经不会影响全局事务的最终结果，这次删不了，那就待会再删，程序删不了，没事顶多人工删。

 

7.5、全局事务回滚流程

如果全局事务的任何一个事务分支失败了，那么全局事务就进入“回滚“流程，回滚时依据先前保存好数据镜像，将原来的数据回放回去。

如果全局回放成功，那么数据的一致性也就得到了保证，如果回放不成功，那么事务就进入异常。应对异常，可能需要重试，可能需要人工介入。