2、分布式基础之一致性协议、2PC和3PC

一、一致性问题

一致性问题：一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。
分布式满足一致性场景：

假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性：(1)全认同(agreement): 所有N个节点都认同一个结果(2)值合法(validity): 该结果必须由N个节点中的节点提出(3)可结束(termination): 决议过程在一定时间内结束，不会无休止地进行下去.

分布式面临的问题：

(1)消息传递异步无序(asynchronous): 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序(synchronous)
(2)节点宕机(fail-stop): 节点持续宕机，不会恢复
(3)节点宕机恢复(fail-recover): 节点宕机一段时间后恢复，在分布式系统中最常见
(4)网络分化(network partition): 网络链路出现问题，将N个节点隔离成多个部分
(5)拜占庭将军问题(byzantine failure): 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息

一致性还具备两个属性，一个是强一致(safety)，它要求所有节点状态一致、共进退；一个是可用(liveness)，它要求分布式系统247无间断对外服务。CAP理论中已经说明了，分布式系统不能同时满足强一致性和高可用性，应该根据具体的业务做取舍，也就是说在分布式系统进行架构设计的过程中，往往会在可用性和一致性之间进行反复的权衡，于是产生了一些列的一致性协议*

二、2PC和3PC

• 当一个事物操作需要跨越多个分布式节点的时候，为了保持事物处理的ACID特征，需要引入一个“协调者”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点称为“参与者”，协调者负责调度参与者的行为，并最终决定这些参与者是都要把事物真正的提交。基于这个思想，衍生出了二阶段提交和三阶段提交两种协议。

1、2PC

2PC:为了使基于分布式系统架构下的所有节点在进行事物处理过程中能够保持原子性和一致性而设计的算法。目前绝大数关系型数据库（比如mysql）都是采用两阶段提交来完成事物处理的。
核心思想：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作
操作过程：

1、提交事物请求（投票阶段）:

• 协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
• 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
• 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息
  2、执行事物提交（执行阶段）：
• 在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

两阶段执行流程图

会产生的问题：

（1）同步阻塞。在两阶段提交的执行过程中，所有的参与者操作的逻辑都是处于阻塞状态，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。coordinator如果在发起提议后宕机，那么participant将进入阻塞(block)状态、一直等待coordinator回应以完成该次决议。
（2）单点问题。协调者会有单点问题。
（3）数据不一致。网络原因或者其他原因会导致部分commit部分没有执行commit，产生数据不一致。
（4）太过保守。就是说在两阶段中，任意一个节点的失败都会导致整个事物失败。

2、3PC

三阶段提交：三阶段提交协议在协调者和参与者中都引入超时机制，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。形成canCOmmit、PreCommit、和doCommit三个阶段组成的事物处理协议。

3PC执行流程图

与2PC比较：（1）相对于2PC，3PC能降低参与者阻塞范围，主要通过参与者引入超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到cohort的消息则默认失败）（3）2PC的准备阶段和提交阶段之间，插入预提交阶段，使3PC拥有CanCommit、PreCommit、DoCommit三个阶段。PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。（极端情况下面还是会出现不一致，如果进入PreCommit后，Coordinator发出的是abort请求，假设只有一个Cohort收到并进行了abort操作，而其他对于系统状态未知的Cohort会根据3PC选择继续Commit，此时系统状态发生不一致性。）
3PC如何应对宕机：

在阶段1中: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
在阶段2中: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
在阶段3中: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务