分布式事务协议的背景
随着网络时代的快速发展，并发量越来越高、数据量越来越多的压力，使得大型项目不得不重新考虑网站架构在高可用、易伸缩、可扩展以及安全等问题。
因此为了解决高可用架构，于是发布式系统应用而生。而分布式为了保证数据的高可用，通常，我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。为了对用户提供正确的增\删\改\差等语义，我们需要保证这些放置在不同物理机器上的副本是一致的。
然而分布式一致性上存在很多问题，各种大佬在性能与数据一致上反复权衡，总结出了一些比较经典的协议及算法。
1. XA规范
XA规范是指 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。
DTP的全称是Distributed Transaction Processing，既分布式事务处理。
X/Open DTP相关介绍如下：
X/Open 组织（即现在的 Open Group ）定义了分布式事务处理模型。 X/Open DTP 模型（ 1994 ）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。
一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，常见的通信资源管理器（CRM）是消息中间件。
通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。
一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。
全局事务：
所谓全局事务是指：多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务
（这在分布式事务中很常见）。
例如：一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。
此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，
还要依赖与全局事务相关的其它数据库的操作是否成功，
如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。
2.二阶段提交协议（2PC）
二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。
2PC简单解读:
参与者（资源管理器）将操作成败通知协调者（事务管理器），再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。类似团队开发，组员（参与者）的目标是否完成会和组长（协调者）报告，组长再根据情况决定是否要上新功能。
顾名思义，二阶段是由两个阶段组成：
- 第一阶段准备阶段(投票阶段）
事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交。redo是物理日志，undo是逻辑日志，在事务失败恢复数据有用到，这边不做详细述说。
一阶段的操作步骤：
<1> 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
<2>参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
（注意：若成功这里其实每个参与者已经执行了事务操作）
<3>各参与者节点响应协调者节点发起的询问。
如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；
如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
- 第二阶段提交阶段(执行阶段）
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
图1.1
二阶段操作成功步骤如下：
<1>协调者节点向所有参与者节点发出”正式提交(commit)”的请求。
<2>参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
<3>参与者节点向协调者节点发送”完成”消息。
<4>协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。
图1.2
二阶段操作失败步骤如下：
<1>协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。
<2>参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
<3>参与者节点向协调者节点发送”回滚完成”消息。
<4>协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。
3.二阶段提交协议（2PC）存在的问题
现在看来好像2PC确实能够很好地保证事务的发展，解决了分布式原子性弱的问题。
但其实不然，2PC同时还存在很多问题，不能保证原子性：
- 单点故障问题
协调者的出现虽然解决了很多问题，但是使得各个节点和协调者之间的耦合度变高了。一旦协调者发生故障，那么事务会一直处于阻塞状态（如果没有设置事务超时时间）。如果在第二阶段协调者发生故障，那么所有的参与者都会因为没有收到协调者的信息，从而都处于锁定事务的状态中。
点评：是个比较大的缺陷，因为就算重新选举一个协调者也无法解决因为上一个协调者故障而导致的参与者处于阻塞状态的问题。
-
同步阻塞问题
执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。 -
数据不一致问题
在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
点评：数据对于一些行业来说是非常看重的，比如金融产业。所以在涉及金融操作时，尽量使用二阶段提交来完成该操作。 -
极端情况
协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
