一、前言

事务（Transaction）：一般是指要做的或所做的事情，由 事务开始(begin transaction) 和 事务结束(end transaction) 之间执行的全体操作组成。

简单地讲就是：要么全部被执行，要么就全部失败。

那分布式事务，自然就是运行在分布式系统中的事务，是由多个不同的机器上的事务组合而成的。同上，只有分布式系统中所有事务执行了才能是成功，否则失败。

事务的基本特征ACID：

原子性（Atomicity）： 一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。
一致性： 指事务执行前和执行后，数据是完整的。
隔离性： 一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
持久性： 也称为永久性，一个事务一旦提交，它对数据库中数据的改变就应该是永久性地保存下来了。

二、分布式事务的目标和实际应用场景

分布式事务的目标：解决多个独立事务一致性的问题。

比如说我们有一个功能，订单系统，横跨了多个微服务，由于每个微服务不在一个库，没法用数据库事务来保证事务，那么这个时候我们就可以使用分布式事务

例如： 商城项目，有用户支付了一个订单，在支付系统中，支付表进行了更新，在另一个订单系统中，订单库里面订单的状态就要变成已支付，那么在订单表和支付表，他们在不同的库，如何保证两个数据库之间的事务呢

支付操作：支付修改余额，修改订单状态

三、分布式事务解决方案

二阶段提交协议（2PC）
三阶段提交协议（3PC）
补偿事务（TCC）
消息中间件实现
seata框架

四、二阶段提交协议（2PC）

基于XA协议的，采取强一致性，遵从ACID

2PC：（2阶段提交协议），是基于XA/JTA规范。

4.1 XA

XA是由X/Open组织提出的分布式事务的架构（或者叫协议）。XA架构主要定义了 （全局）事务管理器（Transaction Manager）和（局部）资源管理器（Resource Manager）之间 的接口。

XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。也就是说，在基于XA的一个事务中，我们可以针对多个资源进行事务管理，例如一个系统访问多个数据库，或即访问数据库、又访问像消息中间件这样的资源。这样我们就能够实现在多个数据库和消息中间件直接实现全部提交、或全部取消的事务。XA规范不是java的规范，而是一种通用的规范。

4.2 JTA

JTA(Java Transaction API)，是J2EE的编程接口规范，它是XA协议的JAVA实现。它主要定义了：

一个事务管理器的接口

javax.transaction.TransactionManager，定义了有关事务的开始、提交、撤回等操作。一个满足XA规范的资源定义接口javax.transaction.xa.XAResource，一种资源如果要支持JTA事务，就需要让它的资源实现该XAResource接口，并实现该接口定义的两阶段提交相关的接口。

4.3 流程图

4.4 提交过程

1.请求阶段，（commit-request phase，或称表决阶段，voting phase），步骤（1-5）在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。

2.提交阶段（commit phase），步骤（6-7）在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

4.5 缺点

单点故障：事务的发起、提交还是取消，均是由老大协调者管理的，只要协调者宕机，那就凉凉了。
同步阻塞缺点：从上面介绍以及例子可看出，我们的参与系统中在没收到老大的真正提交还是取消事务指令的时候，就是锁定当前的资源，并不真正的做些事务相关操作，所以，整个分布式系统环境就是阻塞的。
数据不一致缺点：就是说在老大协调者向小弟们发送真正提交事务的时候，部分网路故障，造成部分系统没收到真正的指令，那么就会出现部分提交部分没提交，因此，这就会导致数据的不一致。

4.6 无法解决的问题

当协调者出错，同时参与者也出错时，两阶段无法保证事务执行的完整性。考虑协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使有了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。知道的人已经被灭口了。

五、三阶段提交协议（3PC）

采取强一致性，遵从ACID。在二阶段上增加了：超时和预提交机制。有这三个主阶段，canCommit、preCommit、doCommit这三个阶段

5.1 流程图

5.2 流程

1.CanCommit阶段： 3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

2.PreCommit阶段： Coordinator根据Cohort的反应情况来决定是否可以继续事务的PreCommit操作。

3.DoCommit阶段： 该阶段进行真正的事务提交，也可以分为以下两种情况:

5.3 缺点

如果进入PreCommit后，Coordinator发出的是abort请求，假设只有一个Cohort收到并进行了abort操作，而其他对于系统状态未知的Cohort会根据3PC选择继续Commit，此时系统状态发生不一致性。

5.4 2PC 和 3PC 的区别

加了询问，增大成功概率。

对于协调者(Coordinator)和参与者(Cohort)都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到cohort的消息则默认失败）。协调者挂了，参与者等待超时后，默认提交事务。有一丢进步。

如果参与者异常了，协调者也异常了，会造成其他参与者提交。

在2PC的准备阶段和提交阶段之间，插入预提交阶段，使3PC拥有CanCommit、PreCommit、DoCommit三个阶段。 PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。

六、基于消息的最终一致性形式

采取最终一致性，遵从BASE理论。

BASE：全称是，Basically Avaliable（基本可用），Soft state（软状态），Eventually consistent（最终一致性）三个短语的缩写，来自eBay的架构师提出。

Basically Avaliable： 就是在分布式系统环境中，允许牺牲掉部分不影响主流程的功能的不可用，将其降级以确保核心服务的正常可用。
Soft state： 就是指在事务中，我们允许系统存在中间状态，且并不影响我们这个系统。就拿数据库的主从复制来说，是完全允许复制的时候有延时的发生的。
Eventually consistent： 还是以数据库主从复制为例说，虽然主从复制有小延迟，但是很快最终就数据保持一致了。

分布式事务不可能100%解决，只能提高成功概率。两阶段之间时间，毫秒级别。补救措施：定时任务补偿。程序或脚本补偿。人工介入。

七、TCC

解决方案：TCC（Try、Confirm、Cancel），两阶段补偿型方案。

从名字可以看出，实现一个事务，需要定义三个API：预先占有资源，确认提交实际操作资源，取消占有=回滚。

如果后两个环节执行一半失败了，记录日志，补偿处理，通知人工。

2PC：是资源层面的分布式事务，一直会持有资源的锁。
    如果跨十几个库，一下锁这么多数据库，会导致，极度浪费资源。降低了吞吐量。
TCC：在业务层面的分布式事务，最终一致性，不会一直持有锁。将锁的粒度变小，每操作完一个库，就释放了锁。
    

都是相对的：如果每天只有一个请求，用2PC 比 TCC 要性能高。因为tcc多了多次接口调用。而此时的2PC 不怕占用资源，反正就一个调用。高并发场景下TCC 优势要大。