其实三者都是为了解决分布式一致性问题而存在的协议和算法。首先先来了解几个概念。

协调者（coordinator）：在分布式系统中，当事务操作需要跨越多个分布式节点的时候，为了保持分布式处理的ACID特性，需要引入它来统一调度所有节点的执行逻辑。
参与者（participant）：协调者调度的这些节点就是参与者了

在实际的过程中，协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正进行提交。
一：二阶段提交协议

1.投票阶段

协调者向所有的参与者发送事务的内容，询问是否可以执行事务，提交操作然后等待参与者的回复。
参与者节点收到讯息，执行事务操作，并将undo和redo信息记录到日志信息中。
然后参与者将是否执行事务的结果反馈给协调者，如果成功执行就返回Yes否则返回No。

2.执行阶段

2.1如果都是返回Yes，则执行事务提交

协调者向所有的参与者节点发出commit请求。
参与者收到commit的请求后，会正式的执行事务并提交。完成提交之后释放所有的事务资源。
参与者完成提交之后会向协调者发送ack的消息。
协调者收到ack之后表示此次事务完成。

2.2如果有返回是No，则执行中断事务

协调者向所有的参与者节点发送Rollback的请求。
参与者收到请求后会利用其在第一阶段记录的undo日志信息来执行事务回滚操作。释放资源。
完成回滚之后，参与者会向协调者发送ack的消息。
协调者收到所有的参与者的ack之后，完成事务中断。

一阶段



二阶段


那么二阶段提交会有哪些问题呢？

首先，由于投票阶段需要等待所有的都给协调者反馈才会进行下一个阶段，那么显而易见的出现了同步阻塞的问题。每个参与者都会等待，直到到了下一个阶段。

其次，我们考虑这么一种情况，如果协调者挂了，是不是都会一直等待？这也就是我们所说的单点问题。

再然后，如果在二阶段在协调者发送commit的时候出现了局部的网络异常，导致有一部分参与者收到了消息，一部分参与者并没有收到消息，这就导致了数据的不一致。

最后，这种方式其实他过于的保守了。
二：三阶段提交

1.canCommit阶段

协调者发送cancommit的请求。参与者返回是否可以的响应。

2.preCommit阶段

2.1若canCommit阶段都是返回的Yes则直接preCommit，各个参与者记录预提交的redo和undo日志。

2.2若有返回为No的参与者，协调者向所有的参与者发送abort命令。或者等待超时后参与者直接中断事务。

3.doCommit阶段

3.1若都成功，则直接返回ack，参与者提交事务，完成整个流程。

3.2若协调者发现其中的参与者有发送No的，则向所有的参与者发送abort，参与者接到消息或者等待超时后中断任务，进行事务回滚。

仔细的同学可能发现了，如果第三阶段我协调者挂了，或者说出现协调者和参与者无法通信，其他的参与者还是会执行doCommit，那不是必定出现数据不一致嘛？是的，这就是三阶段提交的缺点，但是相较于二阶段提交，它很大程度上减小了参与者的阻塞范围，并且就算出现单点问题最后参与者还是能达成一致，这是我们希望看到的。

分布式系统，这早已不是什么新鲜的东西了，在分布式系统的架构设计过程中，往往会存在分布式一致性的问题，经过前人的辛苦探究，提出了二阶段提交协议，三阶段提交协议，Paxos算法等等，用来解决分布式一致性的问题。今天我就讲一下，二阶段提交协议和三阶段提交协议的过程，以及它们的优缺点。

2PC，就是二阶段提交协议。顾名思义，就是将事务的提交过程分成两个阶段来处理。那我们来看看这两个阶段分别做了什么。

阶段一：

   1.提交事务请求：

      协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

   2.执行事务：

      各个参与者节点执行事务操作。并将Undo和Redo信息记入事务日志中。

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

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

阶段二：

   1.执行事务提交：

      假如协调者从所有参与者获得的响应都为Yes，那么就执行事务提交，协调者向所有参与者节点发出Commit请求。

   2.参与者提交事务：  

      参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源,并向协调者发送Ack消息。

   3.完成事务：

      协调者接收到所有参与者反馈的Ack消息后，完成事务。

这里我画了一张时序图，来说明其中的过程，如图所示：



 

中断事务

假如任何一个参与者反馈给协调者No响应，或者在等待超时之后，协调者没有收到所有参与者的响应，那么就会中断事务。

   1.发送回滚请求

      协调者向所有参与者发送Rollback请求。

   2.事务回滚

     参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，完成回滚之后释放在整个事务执行期间占用的资源，并向协调者发送Ack消息，协调者接收到所有的参与者反馈的Ack消息后，完成事务中断。

中断的过程就是这样，下面一张时序图，描述中断事务的过程。



二阶段提交协议的整个过程就是这样，这种先请求后提交的方式，能够保证所有节点在进行事务处理过程中保持原子性，进行统一的提交或回滚，可以看作是一个强一致性的算法。那我们就来思考一下，它有哪些优点，以及会带来什么问题。

优点：简单好用，实现方便。

缺点：同步阻塞，单点问题，还是会有数据不一致的情况出现。

同步阻塞：在二阶段提交事务的过程中，所有参与该事务操作的逻辑都处于阻塞状态，各个参与者在等待其他参与者的响应过程中，无法做其他的操作。

单点问题：在二阶段提交协议中，协调者这个角色是很重要的，一旦协调者挂掉，将导致整个提交流程无法运转，若是在第二阶段协调者挂掉，参与者将一直处于锁定事务资源的状态，无法继续完成事务操作。

数据不一致：若是在第二阶段，协调者在向所有参与者发送commit请求时，由于局部网络的故障，只有部分参与者受到commit请求，提交事务，这样没有受到commit请求的就没有提交事务，出现了数据不一致的情况。

3PC,就是三阶段提交协议，顾名思义，就是把事务的提交过程分为三个阶段，实际上它就是在原来二阶段提交上做了一部分改进，那我们就来看看它的过程，以及它到底改进了什么。

阶段一：CanCommit

     事务询问：

     协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各个参与者的响应。参与者接收请求后，正常情况下，如果认为其自身可以顺利执行事务，那么会反馈Yes响应，并进入预备状态，否则反馈No响应。

阶段二：PreCommit

在阶段二，协调者根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，正常情况下，包含两种可能。一种是参与者全部反馈Yes响应，则进入预提交阶段，另一种时有参与者反馈No响应或者等待超时后，没有收到全部的反馈响应，则会中断事务，我们来分别看一下这两种情况。

第一种：预提交：

   协调者向所有的参与者发送PreCommit请求，并进入Prepared阶段。

   参与者接收到preCommit的请求，执行事务操作，并将Undo和Redo信息记录到事务日志中，然后向协调者反馈Ack响应，等待最终的指令提交或中止。

第二种：中断事务：

   协调者向所有的参与者发出abort请求，参与者无论是收到协调者的abort请求，还是等待请求过程中超时，参与者都会中断事务。

阶段三：doCommit

这一阶段，即将开始真正的事务提交，同样也会存在两种可能的情况。

第一种：执行提交：

   1.发送提交请求：

      进入这一阶段：假如协调者处于正常的工作状态，并且它接收到了来自所有参与者的Ack响应，那么它将从预提交状态转换到提交状态，并向所有的参与者发送doCommit请求。

   2.事务提交：

     参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源，并向协调者发送Ack消息。协调者接收到所有参与者反馈的Ack消息后，完成事务。

第二种：中断事务：

   进入这一阶段，假设协调者处于正常状态（这个很关键），并且有任意一个参与者向协调者反馈了No响应，或者等待超时之后，协调者无法接收到所有参与者的反馈响应。那么就会中断事务。

   协调者向所有参与者节点发送abort请求。

   各个参与者接收到abort请求后，会利用其在阶段二中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源，并向参与者发送Ack消息。协调者接收到所有参与者反馈的Ack消息后，中断事务。

一旦进入到阶段三，可能会存在两种故障：1.协调者出现问题；2.协调者和参与者之间的网络出现故障。

无论出现哪种情况，最终都会导致参与者无法及时接收到来自协调者doCommit或是abort请求，针对这样的异常情况，参与者都会在等待超时之后，继续提交事务操作。

到这里三阶段提交协议就讲完了，相比较于二阶段提交协议，它降低了参与者的阻塞范围，并在出现单点故障后，继续达成一致。同样三阶段提交协议也会带来数据不一致的问题，在第二阶段，协调者向所有参与者发送preCommit请求时，如果这时网络出现问题，协调者无法和参与者进行正常通信，参与者此时仍然会提交事务，而协调者等待超时后，进行事务中断，这样就会带来数据不一致的情况。

总结：二阶段提交协议和三阶段提交协议都是解决分布式数据一致性问题的优秀算法，尽管从根本上并不能保证绝对的一致性，但也并不影响它们在实际工程上的使用。有句话是这么说的，在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的,有兴趣的朋友可以研究一下paxos算法以及它的证明过程。

由于二阶段提交存在很多的问题，我们对其做了一定的改进，也就是三阶段提交，过程图如下：



主要有2个优化点：

1 引入超时机制。同时在协调者和参与者中都引入超时机制。

2 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

CanCommit阶段

协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

PreCommit阶段

协调者根据参与者的反应情况来决定是否可以进行事务的PreCommit操作。根据响应情况，有以下两种可能。

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。


1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。

2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。


假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。


1.发送中断请求 协调者向所有参与者发送abort请求。

2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。


doCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

执行提交


1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。

2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

3.响应反馈 事务提交完之后，向协调者发送Ack响应。

4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。


中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。


1.发送中断请求 协调者向所有参与者发送abort请求

2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息

4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。


在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。 ）

2PC与3PC的区别

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

要解决的问题：分布式数据一致性(当客户端发起写入数据请求时，各个节点的数据保持一致)

两阶段提交



存在的问题：

同步阻塞： 协调者发起命令后只能无限等待参与者响应
	
单点问题：协调者宕机则整个集群不可用
	
脑裂问题：网络分化后，导致部门节点提交成功，部分节点失败，造成数据不一致
 

Paoxs协议



问题背景：假设我们有下图的系统，想要在server1，server2，server3选一个master。



prepare阶段 

  1. 每个server向proposer发送消息，表示自己要当leader，假设proposer收到消息的时间不一样，顺序是： proposer2 -> proposer1 -> proposer3，消息编号依次为1、2、3。 

  紧接着，proposer将消息发给acceptor中超过半数的子成员(这里选择两个)，如图所示，proposer2向acceptor2和acceptor3发送编号为1的消息，proposer1向acceptor1和accepto2发送编号为2的消息，proposer3向acceptor2和acceptor3发送编号为3的消息。 

   2. 假设这时proposer1发送的消息先到达acceptor1和acceptor2，它们都没有接收过请求，所以接收该请求并返回【pok，null，null】给proposer1，同时acceptor1和acceptor2承诺不再接受编号小于2的请求； 

  紧接着，proposer2的消息到达acceptor2和acceptor3，acceptor3没有接受过请求，所以返回proposer2 【pok，null，null】，acceptor3并承诺不再接受编号小于1的消息。而acceptor2已经接受proposer1的请求并承诺不再接收编号小于2的请求，所以acceptor2拒绝proposer2的请求； 

  最后，proposer3的消息到达acceptor2和acceptor3，它们都接受过提议，但编号3的消息大于acceptor2已接受的2和acceptor3已接受的1，所以他们都接受该提议，并返回proposer3 【pok，null，null】； 

  此时，proposer2没有收到过半的回复，所以重新取得编号4，并发送给acceptor2和acceptor3，此时编号4大于它们已接受的提案编号3，所以接受该提案，并返回proposer2 【pok，null，null】。

accept阶段 

1 

  Proposer3收到半数以上（两个）的回复，并且返回的value为null，所以，proposer3提交了【3，server3】的提案。 

  Proposer1也收到过半回复，返回的value为null，所以proposer1提交了【2，server1】的提案。 

  Proposer2也收到过半回复，返回的value为null，所以proposer2提交了【4，server2】的提案。 

   （这里要注意，并不是所有的proposer都达到过半了才进行第二阶段，这里只是一种特殊情况）

2 

  Acceptor1和acceptor2接收到proposer1的提案【2，server1】，acceptor1通过该请求，acceptor2承诺不再接受编号小于4的提案，所以拒绝； 

  Acceptor2和acceptor3接收到proposer2的提案【4，server2】，都通过该提案； 

  Acceptor2和acceptor3接收到proposer3的提案【3，server3】，它们都承诺不再接受编号小于4的提案，所以都拒绝。

所以proposer1和proposer3会再次进入第一阶段，但这时候 Acceptor2和acceptor3已经通过了提案（AcceptN = 4，AcceptV=server2），并达成了多数，所以proposer会递增提案编号，并最终改变其值为server2。最后所有的proposer都肯定会达成一致，这就迅速的达成了一致。

原文链接：https://blog.csdn.net/u013679744/article/details/79222103

存在问题:

活锁问题：假如提案者1因为不能获得过半响应而将自己的编号变为maxN+1=3，而此时提案者2的提案号是2<3,因此也会将自己的编号maxN+1=4,and so on， 造成活锁问题
ZAB协议

广播模式



无历史数据时，选举leader



有历史数据，则按照zxid, myid 顺序选择最大的节点