分布式事务问题理论模型-蒲公英云

文章目录

- - （一）X/Open分布式事务模型
  - （二）两阶段提交协议
  - - （1）介绍
    - （2）俩阶段提交的缺点
  - （三）三阶段提交协议
  - - （1）介绍
    - （2）两阶段提交和三阶段提交不同分析
  - （四）CAP定理
  - （五）BASE理论

（一）X/Open分布式事务模型

XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。XA协议包括两套函数，以xa_开头的及以ax_开头的。
我们常见的数据库连接事务中的 XA 是指由 X/Open 组织提出的分布式事务处理的规范. XA 规范主要定义了事务管理器(Transaction Manager)和局部资源管理器(Local Resource Manager)之间的接口.
X/Open DTP ( X/Open Distributed Transaction Processing Reference Model ）是X/Open这个组织定义的一套分布式事务的标准。这个标准提出了使用两阶段提交(2PC，Two-Phase-Commit）来保证分布式事务的完整性。X/Open DTP中包含以下三种角色。

·AP : Application,表示应用程序（应用服务，比如下订单服务）
·RM : Resource Manager，表示资源管理器，比如数据库。
·TM: Transaction Manager，表示事务管理器，一般指事务协调者，负责协调和管理事务，提供AP编程接口或管理RM。可以理解为Spring中提供的Transaction Manager。
在这里插入图片描述
【大致操作流程如下】
1：配置TM，把事务参与的多个RM注册到TM中，相当于TM注册RM作为数据源
2：AP从TM管理的RM中获取连接，如果RM是数据库则获取JDBC连接
3：AP向TM发起一个全局事务，生成全局事务ID（XID），XID会通知各个参与的RM
4：AP通过第二步获取的连接直接操作RM完成数据操作。同时，AP在每次操作时会把XID传递给RM
5：AP结束全局事务，TM会通知各个RM全局事务结束
6：根据各个事务的执行结果，执行提交或者回滚操作。

在原本的单机事务下，会存在跨库事务的可见性问题，导致无法实现多节点事务的全局可控。而TM就是一个全局事务管理器，它可以管理多个资源管理器的事务。TM最终会根据各个分支事务的执行结果进行提交或者回滚，如果注册的所有分支事务中任何一个节点事务执行失败，为了保证数据的一致性，TM会触发各个RM的事务回滚操作。

需要注意的是，TM和多个RM之间的事务控制，是基于XA协议（XA Specification)来完成的XA协议是X/Open提出的分布式事务处理规范，也是分布式事务处理的工业标准，它定义了xa_和ax_系列的函数原型及功能描述、约束等。目前Oracle、 MySQL、DB2都实现了XA接口，所以它们都可以作为RM.

在这里插入图片描述

（二）两阶段提交协议

（1）介绍

两阶段提交协议分为准备阶段和提交/回滚阶段。两阶段提交协议的执行流程如下：

准备阶段：事务管理器TM通知资源管理器RM准备分支事务，记录事务日志，并告知事务管理器的准备结果
提交/回滚阶段：如果所有的资源管理器RM在准备阶段都明确返回成功，则事务管理器TM向所有的资源管理器RM发起事务提交指令完成数据的变更。反之，如果任何一个资源管理器RM明确返回失败，则事务管理器TM会向所有的资源管理器RM发起事务回滚指令

（2）俩阶段提交的缺点

两阶段提交将一个事务的处理过程分为投票和执行两个阶段，它的优点在于充分考虑到了分布式系统的不可靠因素，并且采用非常简单的方式(两阶段提交）就把由于系统不可靠而导致事务提交失败的概率降到最小。当然，它也并不是完美的，存在以下缺点。

同步阻塞:所有参与者(RM）都是事务阻塞型的，对于任何一次指令都必须要有明确的响应才能继续进行下一步，否则会处于阻塞状态，占用的资源一直被锁定。
过于保守:任何一个节点失败都会导致数据回滚。（在某些事务过程要求不那么严格的情况下，在部分场景中非核心流程的失败是可以允许的）
事务协调者的单点故障:如果协调者在第二阶段出现了故障，那么其他的参与者(RM）会一直处于锁定状态。
“脑裂”导致数据不一致问题:在第二阶段中，事务协调者向所有参与者(RM）发送commit请求后，发生局部网络异常导致只有一部分参与者(RM )接收到了commit请求，这部分参与者(RM ）收到请求后会执行commit操作，但是未收到commit请求的节点由于事务无法提交，导致数据出现不一致问题。

（三）三阶段提交协议

（1）介绍

三阶段提交协议是两阶段提交协议的改进版本，它利用超时机制解决了同步阻塞的问题，三阶段提交协议的具体描述如下.

CanCommit(询问阶段）:事务协调者向参与者发送事务执行请求，询问是否可以完成指令，参与者只需要回答是或者不是即可，不需要做真正的事务操作，这个阶段会有超时中止机制。

PreCommit (准备阶段）:事务协调者会根据参与者的反馈结果决定是否继续执行，如果在询问阶段所有参与者都返回可以执行操作，则事务协调者会向所有参与者发送PreCommit请求，参与者收到请求后写redo和undo日志，执行事务操作但是不提交事务，然后返回ACK响应等待事务协调者的下一步通知。如果在询问阶段任意参与者返回不能执行操作的结果，那么事务协调者会向所有参与者发送事务中断请求。

DoCommit(提交或回滚阶段）:这个阶段也会存在两种结果，仍然根据上一步骤的执行结果来决定DoCommit的执行方式。如果每个参与者在PreCommit阶段都返回成功，那么事务协调者会向所有参与者发起事务提交指令。反之，如果参与者中的任一参与者返回失败，那么事务协调者就会发起中止指令来回滚事务。

（2）两阶段提交和三阶段提交不同分析

1：三阶段增加了一个CanCommit阶段，用于询问所有参与者是否可以执行事务操作并且响应，它的好处是，可以尽早发现无法执行操作而中止后续的行为。
2：三阶段协议在准备阶段之后，事务协调者和参与者都引入了超时机制，一旦超时，事务协调者和参与者会继续提交事务，并且认为处于成功状态，因为在这种情况下事务默认为成功的可能性比较大。

实际上，一旦超时，在三阶段提交协议下仍然可能出现数据不一致的情况，当然概率是比较小的。另外，最大的好处就是基于超时机制来避免资源的永久锁定。需要注意的是，不管是两阶段提交协议还是三阶段提交协议，都是数据一致性解决方案的实现，我们可以在实际应用中灵活调整。比如ZooKeeper集群中的数据一致性，就用到了优化版的两阶段提交协议，优化的地方在于，它不需要所有参与者在第一阶段返回成功才能提交事务，而是利用少数服从多数的投票机制来完成数据的提交或者回滚。

（四）CAP定理

CAP定理，又叫布鲁尔定理。简单来说它是指在分布式系统中不可能同时满足一致性(C:Consistency ) .可用性(A:Availability)、分区容错性( P: Partition Tolerance)这三个基本需求，最多同时满足两个。

C：数据在多个副本中要保持强一致，分布式数据一致性问题
A：系统对外提供的服务必须一直处于可用状态，在任何故障下，客户端都能在合理的时间内获得服务端的非错误响应。
P：在分布式系统中遇到任何网络分区故障，系统仍然能够正常对外提供服务。（单个节点挂掉系统还能够正常提供服务）

不同节点分布在不同的子网络中时，在内部子网络正常的情况下，由于某些原因导致这些子节点之间出现网络不通的情况，导致整个系统环境被切分成若干独立的区域，这就是网络分区。

CAP定理证明，在分布式系统中，要么满足CP，要么满足AP，不可能实现CAP或者CA。原因是网络通信并不是绝对可靠的，比如网络延时、网络异常等都会导致系统故障。而在分布式系统中，即便出现网络故障也需要保证系统仍然能够正常对外提供服务，所以在分布式系统中Partition Tolerance是必然存在的，也就是需要满足分区容错性。

如果是CA或者CAP这种情况，相当于网络百分之百可靠，否则当出现网络分区的情况时，为了保证数据的一致性，必须拒绝客户端的请求。但是如果拒绝了请求，就无法满足A，所以在分布式系统中不可能选择CA，因此只能有AP或者CP两种选择。

AP:对于AP来说，相当于放弃了强一致性，实现最终的一致，这是很多互联网公司解决分布式数据一致性问题的主要选择。（可用性+分区容错性）
CP:放弃了高可用性，实现强一致性。前面提到的两阶段提交和三阶段提交都采用这种方案。可能导致的问题是用户完成一个操作会等待较长的时间。（数据强一直性+分区容错性）

（五）BASE理论

BASE理论是由于CAP中一致性和可用性不可兼得而衍生出来的一种新的思想，BASE理论的核心思想是通过牺牲数据的强一致性来获得高可用性（最终一致性）。它有如下三个特性。

Basically Available(基本可用):分布式系统在出现故障时，允许损失一部分功能的可用性，保址核心功能的可用。
Soft State(软状态):允许系统中的数据存在中间状态，这个状态不影响系统的可用性，也就是允许系统中不同节点的数据副本之间的同步存在延时。
Eventually Consistent（最终一致性):中间状态的数据在经过一段时间之后，会达到一个最终的数据一致性。

BASE理论并没有要求数据的强一致，而是允许数据在一段时间内是不一致的，但是数据最终会在某个时间点实现一致。在互联网产品中，大部分都会采用BASE理论来实现数据的一致，因为产品的可用性对于用户来说更加重要。