分布式系统学习：二阶段提交

CAP理论

在学习分布式的相关知识点前，一定要先掌握CAP定理：

• C(onsistency) 一致性：分布式环境中，CAP关注的粒度是数据，而不是系统，而数据往往存在于多个副本之中，一致性是指多个副本之间，在同一时刻能否有同样的值（内容和组织上的数据）

• A(vailability) 可用性：系统提供的服务必须一直处于可用的状态。即使集群中一部分节点故障。换句话说就是用户在容忍的时间范围内返回用户期望的结果

• P(artition-resiliene) 分区容错性：系统在遇到节点故障，或者网络分区时（断网），依然能对外提供一致性和可用性的服务，在分布式系统架构中，通常由多个节点组成，由于节点通讯往往依赖网络，网络在现实中不是100%可靠的，所以分区容错是分布式的一个 “最基本要求” ，所以一般我们常见的CAP架构只有 AP和CP。

CAP 不能同时满足

一致性、可用性以及分区容错性在度量上也应该有一个评定范围，最简单的以可用性来说，当有多少占比满足出现响应超时可以被认定为是不可满足可用性，而不是一出现超时就认为不可用。

CAP并没有考虑数据同步的耗时，所以在现实中的分布式系统理论上无法保证任何时刻的绝对 “一致性”；不同业务吸引对上述耗时的敏感度是不同的

虽然CAP理论定义的是三个要素只能取两个，但放到实际的分布式环境中来考虑，我们会发现必须选择P（分区容忍）要素，因为既然网络是不可靠的，所以分区是一个必然出现的现象。

假如我们选择CA的架构：当网络故障时，为了满足一致性C，分布式系统协议规定必须禁止写入，当有写入时，会出现error,但因为可用性A的要求，分布式可用只能出现 no error 或 timeout error, 因此从现实中不可能现在CA架构的。

两阶段提交协议2PC

二阶段提交( Two-phaseCommit )是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法( Algorithm )。

通常，二阶段提交也被称为是一种协议( Protocol )。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。

当一个事务跨越多个节点时，为了保持事务的 ACID 特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

概况来说，两阶段提交是需要参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情况决定参与者是否需要提交操作还是中止操作。

两阶段提交（2PC）基于CP系统的思路，是分布式情况下强一致性（当修改操作成功后，当读取改数据副本的时候，一定能读到最新修改的数据）的算法；它是用来保证分布式系统事务的协议。

两阶段是哪两个阶段？

一、Prepare(投票、准备)阶段

该阶段的主要目的在于检测分布式集群中的各个参与者节点是否能够正常的执行事务，具体步骤如下：

1.协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果

2.事务参与者收到请求之后，执行事务但不提交，并记录事务日志；为了保证接下来能提交，每个参与者必须将事务中所发生改变的对象已经自己的状态保存到持久化存储中

3.参与者将自己事务执行情况反馈给协调者，同时阻塞等待协调者的后续指令

二、Accept(提交、执行)阶段

一个参与者在它事务提交前，必须保证能执行提交协议中它自己的那一部分，即使参与者出现故障而不会中途换掉

在经过第一阶段协调者的检测阶段之后，各个参与者会回复自己事务的执行情况，这时候存在三种可能性：

1.所有的参与者都回复能够正常执行事务

2.一个或多个参与者回复事务执行失败

3.协调者等待超时

对于第二、三种情况，协调者均认为参与者无法成功执行事务，即事务失败，为了整个集群数据的一致性，所以要向各个参与者发送事务回滚通知

1.协调者向各个参与者发送事务 rollback 通知，请求回滚事务

2.参与者收到事务回滚通知之后，执行 rollback 操作，然后释放占有的资源

3.参与者向协调者返回事务 rollback 结果信息

两阶段提交的工作流程如图：

• 图片源自： https://blog.acolyer.org/2015/01/21/a-new-presumed-commit-optimisation-for-two-phase-commit/

两阶段提交协议的问题

• 协议是事务阻塞型的：2PC提交执行过程中，所有的参与者都需要听从协调者的统一调度，期间处于阻塞状态而不能从事其它操作

• 数据不一致性、网络容错能力差：这个时候，我们需要引入超时机制或互相轮休的机制降低问题的严重性

• 协调者单点故障：协调者在执行提交阶段宕机，所有的参与者处于锁定事务资源的状态，无法完成事务操作。

正是这些问题，两阶段无法解决以下问题：

协调者发出commit消息后宕机，而唯一接收这消息的参与者同时也宕机，那么协调者即系通过选举或其它恢复方案产生新的可以协调者，这事务的状态也是不确定的。