分布式事务-——1、2PC和3PC原理

本文主要是介绍分布式事务-——1、2PC和3PC原理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1、分布式事务

基本遵循CPA理论，采用柔性事物特征，软状态或者最终一致性特点保证分布式事物一致性问题。

基本理论:

1、CAP理论

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

Consistency 一致性（涉及重要信息如钱财；分布式存储系统必须保证）

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性:

1.强一致性:对于关系型数据库，要求更新过的数据能被后续的访问都能看到.

2.弱一致性：能容忍后续的部分或者全部访问不到。

3.最终一致性：经过一段时间后要求能访问到更新后的数据。

Availability 可用性（大型互联网为了服务可用，舍弃强一致性，保证最终一致性）

服务一直可用，而且是正常响应时间

Partition Tolerance分区容错性(分布式必须要考虑的问题

分布式系统在遇到某节点或网络故障的时候，仍然能够对外提供满足一致性和可用性的服务。就是在网络中断的情况下，系统如果还能正常工作

不同情况简介：

CA(一致性+可用性）without P（容错性）单机的Mysql和Oracle；分布式集群中不存在这种情况，因为多个节点必定考虑主备同步，也就是网络。

    CP(一致性+容错性）without A（可用性）分布式的数据库，如Redis，HBase，Zookeeper任何时刻对ZooKeeper请求能得到一致的数据结果:当master节点网络故障，会进行选举机制，选举时集群不可用。但是它不能保证每次服务请求的可用性，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果。

    AP(可用性+容错性）without C（一致性）12306买票购买的时候提示你是有票的（但是可能实际已经没票了），但是过了一会系统提示你下单失败，余票不足。其实舍弃的只是强一致性。退而求其次保证了最终一致性。Eureka各个节点平等；有节点挂掉，会立刻换至其他节点，保证服务可用，只不过查到的信息可能不是最新的。在网络稳定后，当前实例新的注册信息会被同步到其他节点中。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，导致全局数据的不一致性。

2、BASE理论

BASE理论是实现分布式事务最终一致性的有效解决方案。

　BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

1、基本可用基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒。（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

2、软状态软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3、最终一致性最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

2、两阶段提交（2PC）

摘自https://www.cnblogs.com/qdhxhz/p/11167025.html

两阶段提交又称2PC,2PC是一个非常经典的强一致、中心化的原子提交协议。

这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）

两个阶段：第一阶段：投票阶段 和第二阶段：提交/执行阶段。

举例 订单服务A，需要调用 支付服务B 去支付，支付成功则处理购物订单为待发货状态，否则就需要将购物订单处理为失败状态。

那么看2PC阶段是如何处理的

1、第一阶段：投票阶段

第一阶段主要分为3步

1）事务询问

协调者 向所有的 参与者 发送事务预处理请求，称之为Prepare，并开始等待各 参与者 的响应。

2）执行本地事务

各个 参与者 节点执行本地事务操作,但在执行完成后并不会真正提交数据库本地事务，而是先向 协调者 报告说：“我这边可以处理了/我这边不能处理”。.

3）各参与者向协调者反馈事务询问的响应

如果 参与者 成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行,如果没有 参与者 成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。

第一阶段执行完后，会有两种可能。1、所有都返回Yes. 2、有一个或者多个返回No。

2、第二阶段：提交/执行阶段（成功流程）

成功条件：所有参与者都返回Yes。

第二阶段主要分为两步

1)所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交

协调者 向 所有参与者 节点发出Commit请求.

2)事务提交

参与者 收到Commit请求之后,就会正式执行本地事务Commit操作,并在完成提交之后释放整个事务执行期间占用的事务资源。

3、第二阶段：提交/执行阶段（异常流程）

异常条件：任何一个 参与者 向 协调者 反馈了 No 响应,或者等待超时之后,协调者尚未收到所有参与者的反馈响应。

异常流程第二阶段也分为两步

1)发送回滚请求

协调者 向所有参与者节点发出 RoollBack 请求.

2)事务回滚

参与者 接收到RoollBack请求后,会回滚本地事务

4、2PC缺点

通过上面的演示，很容易想到2pc所带来的缺陷

`1、性能问题`

无论是在第一阶段的过程中,还是在第二阶段,所有的参与者资源和协调者资源都是被锁住的,只有当所有节点准备完毕，事务 协调者 才会通知进行全局提交，

参与者 进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大。

`2、单节点故障`

由于协调者的重要性，一旦 协调者 发生故障。参与者 会一直阻塞下去。尤其在第二阶段，协调者 发生故障，那么所有的 参与者 还都处于

锁定事务资源的状态中，而无法继续完成事务操作。（虽然协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

2PC出现单点问题的三种情况

协调者正常,参与者宕机

由于协调者无法收集到所有参与者的反馈，会陷入阻塞情况。

解决方案:引入超时机制,如果协调者在超过指定的时间还没有收到参与者的反馈,事务就失败,向所有节点发送终止事务请求。

协调者宕机,参与者正常

无论处于哪个阶段，由于协调者宕机，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况.

解决方案:引入协调者备份,同时协调者需记录操作日志.当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态。

协调者和参与者都宕机

1) 发生在第一阶段：因为第一阶段，所有参与者都没有真正执行commit，所以只需重新在剩余的参与者中重新选出一个协调者，新的协调者在重新执行第一阶段和第二阶段就可以了。

2)发生在第二阶段并且挂了的参与者在挂掉之前没有收到协调者的指令。也就是上面的第4步挂了，这是可能协调者还没有发送第4步就挂了。这种情形下，新的协调者重新执行第一阶段和第二阶段操作。

3)发生在第二阶段并且有部分参与者已经执行完commit操作。就好比这里订单服务A和支付服务B都收到协调者发送的commit信息，开始真正执行本地事务commit,但突发情况，Acommit成功，B确挂了。这个时候目前来讲数据是不一致的。虽然这个时候可以再通过手段让他和协调者通信，再想办法把数据搞成一致的，但是，这段时间内他的数据状态已经是不一致的了！ 2PC 无法解决这个问题。

3、三阶段提交(3PC)

三阶段提交协议（3PC）主要是为了解决两阶段提交协议的阻塞问题，2pc存在的问题是当协作者崩溃时，参与者不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞。三阶段提交（Three-phase commit），是二阶段提交（2PC）的改进版本。

与两阶段提交不同的是，三阶段提交有两个改动点。

1、 引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段前插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的

1、CanCommit阶段

之前2PC的一阶段是本地事务执行结束后，最后不Commit,等其它服务都执行结束并返回Yes，由协调者发生commit才真正执行commit。而这里的CanCommit指的是 尝试获取数据库锁 如果可以，就返回Yes。

这阶段主要分为2步

事务询问 协调者 向 参与者 发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待 参与者 的响应。
响应反馈 参与者 接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No