什么是分布式事务？
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
例如：
图中包含了库存和订单两个独立的微服务，每个微服务维护了自己的数据库，在交易系统的业务逻辑中，一个商品在下单之前需要先调用库存服务，进行扣除库存，再调用订单服
务，创建订单记录。
正常情况下，两个数据库各自更新成功，两边数据维持着一致性。
如果在非正常情况下，有可能库存的扣减完成了，随后的订单记录却因为某些原因插入失败，或者是订单创建成功了，但是库存扣除商品的数据量失败了，这个时候，两边数据就
失去了应有的一致性。
这时候就需要保证事务的一致性了，单数据源的用单机事务来保证。多数据源就需要依赖分布式事务来处理。
XA 的两阶段提交方案
什么是 XA 协议
XA 协议由 Oracle Tuxedo 首先提出的，并交给 X/Open 组织，作为资源管理器（数据库）与事务管理器的接口标准。
目前，Oracle、Informix、DB2 和 Sybase 等各大数据库厂家都提供对 XA 的支持。
XA 协议采用两阶段提交方式来管理分布式事务。
XA 接口提供资源管理器与事务管理器之间进行通信的标准接口。
XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。
XA 接口函数由数据库厂商提供。
X/Open 组织（即现在的 Open Group）定义了分布式事务处理模型。
X/Open DTP 模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理 器（CRM）四部分。
一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，常见的通信资源管理器（CRM）是消息中间件。
XA 协议的一阶段提交 ：
如果在程序中开启了事务，那么在应用程序发出提交/回滚请求后，数据库执行操作，而后将成功/失败返回给应用程序，程序继续执行。
一阶段提交协议相对简单。优点也很直观，它不用再与其他的对象交互，节省了判断步骤和时间，所以在性能上是在阶段提交协议中最好的。
但缺点也很明显：
数据库确认执行事务的时间较长，出问题的可能性就随之增大。如果有多个数据源，一阶段提交协议无法协调他们之间的关系。
XA 协议的二阶段提交：
在一阶段协议的基础上，有了二阶段协议，二阶段协议的好处是添加了一个管理者角色。
很明显，二阶段协议通过将两层变为三层，增加了中间的管理者角色，从而协调多个数据源之间的关系，二阶段提交协议分为两个阶段。
应用程序调用了事务管理器的提交方法，此后第一阶段分为两个步骤：
事务管理器通知参与该事务的各个资源管理器，通知他们开始准备事务。
资源管理器接收到消息后开始准备阶段，写好事务日志并执行事务，但不提交，然后将是否就绪的消息返回给事务管理器（此时已经将事务的大部分事情做完，以后的内容耗时极
小）。
第二阶段也分为两个步骤：
事务管理器在接受各个消息后，开始分析，如果有任意其一失败，则发送回滚命令，否则发送提交命令。
各个资源管理器接收到命令后，执行（耗时很少），并将提交消息返回给事务管理器。
事务管理器接受消息后，事务结束，应用程序继续执行。
为什么要分两步执行？
一是因为分两步，就有了事务管理器统一管理的机会，二尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶
段将是耗时极短，耗时极短意味着操作失败的可能性也就降低。
同时，二阶段提交协议为了保证事务的一致性，不管是事务管理器还是各个资源管理器，每执行一步操作，都会记录日志，为出现故障后的恢复准备依据。
缺点：
1、二阶段提交协议的存在的弊端是阻塞，因为事务管理器要收集各个资源管理器的响应消息，如果其中一个或多个一直不返回消息，则事务管理器一直等待，应用程序也被阻塞， 甚至可能永久阻塞。
2、两阶段提交理论的一个广泛工业应用是 XA 协议。
目前几乎所有收费的商业数据库都 支持 XA 协议。XA 协议已在业界成熟运行数十年，但目前它在互联网海量流量的应用场景中，吞吐量这个瓶颈变得十分致命，因此很少被用到。
TCC 解决方案：
TCC 介绍 ：
TCC 是由支付宝架构师提供的一种柔性解决分布式事务解决方案,主要包括三个步骤 ：
Try：预留业务资源/数据效验
Confirm：确认执行业务操作
Cancel：取消执行业务操作
TCC 原理：
TCC 方案在电商、金融领域落地较多。TCC 方案其实是两阶段提交的一种改进，其将整个业务逻辑的每个分支显式的分成了 Try、Confirm、Cancel 三个操作。
Try 部分完成业务的准备工作，confirm 部分完成业务的提交，cancel 部分完成事务的回滚。
基本原理如下图所示：
事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务 的 try 接口，完成一阶段准备。之后事务协调器会根据 try 接口返回情况，决定调用 confirm 接口或者 cancel 接口。
如果接口调用失败，会进行重试。
微服务倡导服务的轻量化、易部署，而 TCC 方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。
TCC 的关键流程如下图(以创建订单和扣减库存为例子) ：
TCC 优缺点 ：
TCC 优点：
让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
TCC 不足之处：
对应用的侵入性强。业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作，应用侵入性较强，改造成本高。
实现难度较大，需要按照网络状态、系统故障等不同的失败原因实现不同的 回滚策略。
为了满足一致性的要求，confirm 和 cancel 接口必须实现幂等。
分布式事务中间件解决方案：
分布式事务中间件其本身并不创建事务，而是基于对本地事务的协调从而达到事务一致性的效果。
典型代表有：阿里的 GTS（https://www.aliyun.com/aliware/txc）、开源应用 LCN。
其实现原理如下：
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
