关于分布式事务在面试中可能会被提及的四个问题
1.什么是？
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。(分布式事务就是为了保证不同数据库的数据一致性。)
2.事务补偿机制
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
- Try 阶段主要是对业务系统做检测及资源预留
- Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认
Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。 - Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
举个例子，假入 Bob 要向 Smith 转账，思路大概是：
我们有一个本地方法，里面依次调用
- 首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
- 在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
- 如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。
优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
(
-
如果有海量数据需要处理、或者要求高并发请求的话，同步的事务机制已经是不现实的了，这种情况下必须采用异步事务机制，既分段式的事务
分段式事务一般做法就是把需求任务分段式地完成，通过事务补偿机制来保证业务最终执行成功，补偿机制一般可以归类为2种：
1 ）定时任务补偿：
通过定时任务去跟进后续任务，根据不同的状态表确定下一步的操作，从而保证业务最终执行成功，
2） 消息补偿：
通过消息中间件触发下一段任务，既通过实时消息通知下一段任务开始执行，执行完毕后的消息回发通知来保证业务最终完成；
当然这也是异步进行的，但是能保证数据最终的完整性、一致性，也是近几年比较热门的做法)3.两阶段提交(2PC)
- 二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。
通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。
因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
所谓的两个阶段是指：
- 第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。
事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息 - 准备阶段
事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交 - 提交阶段
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
二阶段提交还是有几个缺点的：
- 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
- 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
- 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
- 二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
4.阿里巴巴 GTS （收费）
GTS是一款也是唯一一款专注于分布式事务问题的中间件。我们把它定义为一站式的分布式事务解决方案。也就是说有了GTS之后，用户不再需要考虑到回滚接口的开发，幂等，以及分布式事务引发的其它异常等等。只需要接入GTS，GTS可以保证应用的所有事务问题。
GTS跟这三者不同点在于，它既不在资源层也不在应用层，它是在中间件层解决事务的问题，这是它们本质的区别。(三点好处：
第二个好处是GTS不在应用层面，就可以解决服务化问题。
第三，它和应用是松耦合的，这样应用会更加清亮)