分布式事务解决方案

本分布式事务系列主要讲分布式事务从

理论-> 解决方案 -> 使用框架 -> 实现及原理 -> 案例实战 -> 事务回滚（全局异常统一处理）->分布式事务消息

该篇着重于讲述分布式事务的解决方案，与各位一起打开新视界的大门。

1.柔性事务与刚性事务

2.传统分布式事务解决方案Jta+Atomikos

3.提交协议2PC与3PC

4.分布式事务解决方案

一、柔性事务与刚性事务

话不多说上理论......

柔性事务满足BASE理论（基本可用，最终一致）

刚性事务满足ACID理论

我们主要围绕分布式事务当中的柔性事务的处理方式进行讨论。

柔性事务分为

1. 两阶段型 2PC 阶段提交（A提交成功 -> B提交成功。AB相互关联，但AB互不影响）

2. 补偿型 --消息中间件（A提交->B提交失败。中间件补偿B，补偿队列，死信队列，后期有案例）

3. 异步确保型 --同步操作，异步确保 （异步与同步.....支付案例了，篇一提到过）

4. 最大努力通知型。

篇一案例中，由于支付宝整个架构是SOA架构，因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的。故这里不进行ACID讨论。

二、传统分布式事务解决方案Jta+Atomikos

这里就是传统项目，使用多数据源，即多个数据库了。所以大多数采用Jta + Atomikos进行解决分布式事务问题。

该框架底层是基于XA协议的两阶段提交方案。

名词含义简介：

XA协议:XA 事务的基础是两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调者收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。Mysql 在这个XA事务中扮演的是参与者的角色，而不是协调者(事务管理器)。

JTA:JTA（java Transaction API）是JavaEE 13 个开发规范之一。java 事务API，允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据。JDBC驱动程序的JTA支持极大地增强了数据访问能力。事务最简单最直接的目的就是保证数据的有效性，数据的一致性

Atomikos:Atomikos TransactionsEssentials 是一个为Java平台提供增值服务的并且开源类事务管理器

Jta + Atomikos只适合在传统项目多数据源情况下使用，底层实现则是2PC（提交协议）

解决原理：

传统项目中唯一可能产生的也就是多数据源，那么多数据源有他独立的事务管理器，所以就会产生事务独立，从而达不到单个方法回滚多个事务。所以产生分布式事务问题，那么jta实现就是将多个事务，整合在一起，通过Jta来进行事务管理，也就是二阶段提交协议。达到回滚多个事务，从而解决分布式事务问题。

三、提交协议2PC与3PC

3.1、2PC

第一阶段：准备阶段：

协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写redo或者undo日志，然后锁定资源，执行操作，但并不提交。

这里可以理解为，小明约小刚与小红这周六去吃饭聚一聚，先通知两位，小刚与小红各自确认自己周六是否能够参与，如果可以参与，就会回复小明各自能去。 

等等...你可能会想叫小红一个妹子不就可以了么？ 答： .......

第二阶段: 提交阶段：

如果每个参与者明确返回准备成功，则协调者向参与者发送提交指令，参与者释放锁定的资源，如果任何一个参与者明确返回准备失败，则协调者会发送中指指令，参与者取消已经变更的事务，释放锁定的资源。

这里可以理解为，小刚与小红如果都能参与这次聚餐，那么小明就认为达到了条件，然后分享餐厅地址给两位参与人，两位参与人得到消息后赶到餐厅完成任务。如果有一方不去，那么取消本次聚餐。

两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

缺点：如果协调者宕机，参与者没有协调者指挥，则会一直阻塞。

如果小明说了周六去聚餐，小刚与小红都同意了，但小明一直不回消息，这里就会造成阻塞。让小刚小红到了周六也一直在等小明回复餐厅在哪儿。结果被放了鸽子，消耗了时间资源。  

等等....你可能会说然后小刚就不能私自和小红去吃了？答： .......

3.2、3PC

第一阶段是表决阶段（询问阶段），所有参与者都将本事务能否成功的信息反馈发给协调者；

第二阶段是执行阶段（准备阶段），协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。

第三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段：

• 询问阶段：

协调者询问参与者是否可以完成指令，参与者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止。

• 准备阶段：

如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致操作不成功。

• 提交阶段：

如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致

3.3、2PC与3PC的区别：

3PC增加了询问机制与超时机制。

增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大、

三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。

四、分布式事务解决方案

常见解决方案：

分布式事务常见解决方案

1. 传统模式使用Jta+Atomikos
2. 2PC与3PC实现的区别
3. 使用TCC补偿框架 （Easy Transaction）
4. 使用可靠消息模式（中间件） 或 同步异步确保 最终一致性（消息补偿）
5. 使用LCN框架解决分布式事务（重点） 第三方 类3PC模式
6. 阿里GTS框架解决分布式事务 Seata
7. 支付案例消息通知 （跨平台 SOA）

后文主要讲

LCN框架解决分布式事务、消息中间件解决分布式事务与并发优化设计、阿里Seata解决分布式事务