分布式协议（一致性算法）_分布式carp-优快云博客

分布式协议（一致性算法）

两阶段提交协议 2PC

  2PC基于如下假设：分布式系统中存在一个协调者和其他参与者，且它们之间网络通信正常。
（1）第一阶段：投票阶段
        首先，协调者向所有参与者发起询问，是否可以执行提交操作，并开始等待每个参与者的响应。
        然后，参与者执行询问发起时为止的所有事务操作，并将信息写入日志（Undo和Redo信息）。其实，如果成功，每个参与者就已经执行了事务操作。
        最后，参与者响应协调者发起的询问。如果参与者的事务实际执行成功，则返回同意的消息，如果参与者的事务操作实际失败，则返回一个中止的消息。
（2）第二阶段：提交执行阶段
    A. 当所有参与者都返回同意时
        1. 协调者向所有的参与者发送"正式提交"的请求。
        2. 所有参与者正式完成操作，并释放正式事务过程中所占用的资源。
        3. 参与者向协调者返回完成的消息。
        4. 协调者接受到参与者的完成消息，完成整个事务。
   B. 一个或多个参与者返回中止消息时
        1. 协调者向参与者发出"事务回滚"的请求。
        2. 参与者利用之前写入的Undo信息，并执行事务的回滚，并释放整个事务期间占用的资源。
        3. 参与者向协调者返回"回滚完成"的消息。
        4. 协调者收到所有协调者的回滚完成消息后，取消事务。

不管最后结果如何，第二阶段都会接受当前事务。

二段事务体提交协议的缺点

（1）同步阻塞：正式事务执行过程中，所有的参与者都是事务阻塞型，当参与者占用公共资源时，其他第三方的节点访问该公共资源时，也不得不进入阻塞状态。
（2）零容错：没有多少容错机制。协调者需要给每个参与者额外指定超时机制，若参与者发送故障，超时后，整个事务失败。
（3）单点：协调者如果发生故障，参与者会一直阻塞下去。则需要额外的备机进行容错。（可以使用Paxos协议实现HA）。
（4）脑裂：当协调者在发出事务提交信息之后宕机，而唯一接收到该消息的参与者同时也出现宕机。即使通过选举产生了新的协调者，当前事务的状态同样处于未知状态，没有人能够知道该事务是否已经被提交了。

三阶段提交协议 3PC

3PC与2PC的差异点：
    （1） 3PC在参与者和协调者中引入了超时机制。
    （2） 在2PC的第一阶段和第二阶段的基础上插入了一个准备阶段，保证了在最后提价阶段之前，各个参与节点的状态是一致的。
    即在引入超时机制的情况下，3PC把2PC的准备阶段一分为二，形成了CanCommit,PreCommit,DoCommit三个阶段。
    CanCommit 阶段
    协调者向参与者发送commit请求，参与者如果可以提交就返回同意，否则返回不同意。
    Ａ. 事务询问：协调者向参与者发送CanCommit的请求，询问是否可以执行事务提交的操作，然后进入等待状态，等待参与者的响应。
    B. 响应反馈：参与者在接受到协调者的CanCommit请求之后，如果认为自身能够进行事务提交，则返回同意响应，进入准备状态，否则返回不同意。
    PreCommit 阶段
    协调者根据参与者响应情况来决定是否进行PreCommit操作。
    A. 当所有的参与者都响应同意的消息，那么执行事务的预执行
        ① 发送预提交请求：协调者向参与者发送PreCommit请求，并进入Prepared阶段。
        ② 事务预提交：参与者接受到协调者的PreCommit请求，进行事务操作，并将Undo和Redo写入事务日志中。
        ③ 响应反馈：如果参与者成功的执行了事务操作，则返回ACK响应（确认消息：是设备或是进程发出的消息，回复已收到数据），同时进入等待状态，等待协调者的最终指令。
   B. 如果任何一个参与者向协调者发送了不同意的消息，或者等待超时之后，协调者都没有接收到参与者的响应，那么就执行事务的终端。
        ① 发送中断请求：协调者向所有参与者发送abort请求（异常终止一个进程）。
        ② 中断事务：参与者收到协调者的abort请求，或者等待超时之后，仍然没有收到协调者的请求，执行事务中断。
    DoCommit 阶段
        该阶段进行真正的事务提交，同样分为以下两种情况：
        A. 执行提交
            ① 发送提交请求：协调者接收到参与者的ACK响应，那么协调者将从预提交状态进入提交状态，并向所有的参与者发送DoCommit请求。
            ② 事务提交：参与者接收到协调者的DoCommit请求后，执行正式的事务提交，并在提交事务之后释放该事务占用的资源。
            ③ 响应反馈：在事务提交之后，参与者向协调者发送ACK响应。
            ④ 完成事务：协调者在接收到所有参与者的ACK响应之后，完成事务。
        B. 中断事务：协调者没有收到参与者的ACK响应，或者接收到非ACK响应以及响应超时等情况的时候，就会执行事务中断操作。主要操作如下：
        ① 发送中断请求：协调者向所有参与者发送abort请求。
        ② 事务回滚：参与者在接收到abort请求之后，利用在第二阶段记录的Undo信息来执行事务的回滚操作，并在回滚完成之后释放所有该事务的占用资源。
        ③ 反馈结果：参与者在完成事务回滚之后，向协调者发送ACK响应。
        ④ 中断事务： 协调者在接收到参与者反馈的ACK响应之后，执行事务的中断。
        注：进入该阶段后，无论协调者出现什么问题（协调者宕机、参与者和协调者网络异常）导致参与者无法接收到协调者发送的DoCommit请求或Abort请求，参与者都会在等待超时之后，继续提交事务。

3PC的优缺点

（1）优点：降低了阻塞范围，在等待超时后，协调者或参与者会中断事务，避免了2PC中协调者的单点问题，但在第三阶段，若协调者出现问题，参与者会继续提交事务。
（2）缺点：脑裂问题依然存在，即当参与者在收到PreCommit请求之后，进入等待最终指令状态，如果协调者无法和参与者进行通信，会导致参与者继续提交事务，导致数据不一致。

无论2PC还是3PC均无法彻底解决分布式一致问题，唯有Paxos。