概述
CAP理论告诉我们由于分布式系统总是存在通信异常，网络分区，节点故障等问题，无法同时保证一致性，可用性，分区容错性。而分区容错性是分布式系统必备的特性，因为分布式系统一定是由不同的机器组成，而这也必然会导致网络分区。因此，我们的系统往往会是可用性和一致性之前做选择。本文将为大家详细介绍分布是一致性保证方案--2pc和3pc。
分布式一致性协议
我们常常遇到的分布式一致性问题大致有两类：
（1）如何保证一次写操作在分布式系统的原子性，即保证要么操作在所有节点中都成功，要么都失败；
（2）如何保证分布式系统快速的就某个值达成一致性（如选主，主从同步等），并且即使发生宕机或者网络异常都不会破坏整个系统的一致性。
对于问题（1），两阶段提交协议2pc和三阶段提交协议3pc是常用的方式，如绝大部分关系型数据库都使用2pc实现分布式事务，这也是本篇博客要介绍的内容。问题（2）就更加的有意思了，我们知道高可用性系统（HA）最常用的解决方式就是维护多个副本来保证主宕机后，副本可以快速顶上，问题（2）就是在主副系统中必然面对的问题。Paxos，Raft协议和Zab协议就是为了解决该问题，本人计划在下一篇博客中来介绍该问题的解决方案。
当然两类问题并不是完全隔离的，问题（1）是保证一次操作的原子性，问题（2）中必然会涉及写操作在主副本间的写操作提交。在后面的讲解中，我们将看到无论Raft协议还是Zab协议都会借鉴2pc的思想进行写操作的提交。
两阶段提交协议2pc
首先我们再看下问题（1），要想解决该问题必须有一定机制让系统中的节点了解到其他节点是否全部执行成功或者存在执行失败，这样节点才能根据该信息来进行回滚或者提交。2pc和3pc通过引入“协调者”角色来实现这个功能，分布式系统中节点的执行提交统一由协调者调度。
顾名思义，2pc就是将以此事务的提交分为两个阶段：提交事务请求和执行事务请求。具体流程如下图所示，其中提交阶段为1，2，3，执行事务阶段为4，5，6。
提交事务阶段：
1.协调器向分布式系统的所有节点（参与者）发送事务询问请求，询问参与者是否可以执行本次事务；
2.各个参与者收到请求后执行事务；
3.各个参与者将事务的执行结果返回给协调者；
执行事务请求阶段：
4.如果所有参与者都执行成功，事务协调者向参与者发送commit命令；如果存在一个参与者执行失败，事务协调者向参与者发送rollback命令；
5.事务参与者收到commit命令后就提交本次事务的执行；如果事务参与者收到rollback命令就回滚本次执行；
6.事务参与者向协调者发送执行的ack；
从上述流程，我们看到2pc用最朴实的方式实现了一套分布式事务解决方案，该协议简单明了易于实现，被广泛应用，如关系型数据库中的分布式事务一般都是通过2pc实现的。但是该协议依然会存在以下问题：
（1）同步阻塞问题：在参与者执行完步骤2后，其持有的资源处于锁定状态，一直等到步骤5执行完成后才会释放资源，这将严重影响参与者的并发性；
（2）单点问题：整个协议的运行完全依赖协调者来执行，一单协调者出现问题整个系统基本处于崩溃状态；
（3）数据不一致性：分布式环境中网络最无法保证的，假设在步骤4中参与者A收到commit命令，而参与者B没有收到commit命令或者收到命令后参与者B崩溃。这样参与者A提交了事务，参与者B没有提交事务就会造成数据的不一致现象。
三阶段提交协议3pc
基于2pc的上述问题，3pc被提出来。如上分析，2pc协议在步骤2执行后，其持有的资源一直被锁定直到整个流程结束，这是一个很长的过程。是否可以将资源锁定后置，已减小同步阻塞的范围？3pc就是按照这个思路去解决2pc中的同步阻塞问题。3pc分为3个阶段分别是canCommit阶段，preCommit阶段，doCommit阶段，其中preCommit阶段和doCommit阶段流程大致和2pc一致，而canCommit阶段是3pc新增的，具体流程如下：
通过在预提交前引入事务询问canCommit，可以确保锁定资源的请求大概率是事务执行成功的，进而可以在一定程度上缓解同步阻塞问题。相比于2pc，3pc中参与者引入了超时中断机制，在doCommit阶段，如果由于网络原因或者协调者单点故障，参与者一直没有收到doCommit命令，那么参与者会在等待一定时间后触发超时机制，自动提交事务。做出这样的操作是因为进入doCommit阶段，大概率是需要成功提交的。当然，也有可能是协调者的abort命令丢失，这种情况下就会造成数据不一致问题，这在2pc协议中也是存在，解决这个问题只能通过我们Paxos，Raft协议来完成。
可以看到相比于2pc，3pc在一定程度上降低了参与则的阻塞范围，并在协调者出现单点故障的时候参与者可以通过超时机制继续提交事务
参考
《从Paxos到Zookeeper分布式一致性原理与实践》
