B )、当协调者出错，同时参与者也出错时，两阶段无法保证事务执行的完整性。
考虑协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。
那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
B 、三阶段提交
三阶段提交拥有 CanCommit 、 PreCommit 、 DoCommit 三个阶段
( 1 )其中 CanCommit 阶段近似等同于两阶段的请求阶段;DoCommit 近似等同于两阶段的提交阶段。而准备阶段 PreCommit 是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。
( 2 )三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段( PreCommit )，使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
( 3 )三阶段提交无法解决的问题
如果进入 PreCommit 后，协调者发出的是 commit 请求，假设只有一个参与者收到并进行了 commit 操作，而其他参与者对于网络中断没有收到，会根据 3PC 选择 abort 操作，此时系统状态发生不一致性。
C 、 Paxos 协议
要讲 Paxos ，先要从拜占庭问题讲起，其故事背景是这样的：拜占庭位于现在土耳其的伊斯坦布尔，是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔，为了防御目的，因此每个军队都分隔很远，将军与将军之间只能靠信差传消息。在战争的时候，拜占庭军队内所有将军必需达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，军队可能有叛徒和敌军间谍，这些叛徒将军们会扰乱或左右决策的过程。这时候，在已知有成员谋反的情况下，其余忠诚的将军在不受叛徒的影响下如何达成一致的协议，这就是拜占庭将军问题。
我们否定假设，给出了非拜占庭模型定义：
( 1 )一致性模块的行为可以以任意速度执行，允许运行失败，在失败后也许会重启并再次运行;
( 2 )一致性模块之间通过异步方式发送信息通信，通信时间可以任意长，信息可能会在传输过程中丢失，也允许重复发送相同的信息，多重信息的顺序可以任意。但是有一点：信息不允许被篡改。
由此，我们得出了 Paxos 的基本二阶段：Prepare 阶段、 Accept 阶段，这个两个阶段的逻辑非常复杂，是互信算法的基础，本文并不打算做过深的解读。有兴趣的读者可以去参考《区块链算法》一书。
D 、 Raft 协议
Raft 是 Replicated And Fault Tolerant 的缩写， Paxos 的简化版本。
在一个分布式系统中，要提高系统的健壮性，可用性和数据的安全性，我们最正确的姿势是什么?当然是靠多备份了，服务多备份，数据多备份，去除单点，确保即使相关组件挂掉一些，系统还能健康服务。
去除单点，没有固定不变的权威，固然好，但是带来的问题就是，以谁的意见为准，在信息可能丢失的环境下，这是一个相当困难的事(可见沟通是多么的重要)!
在 1990 年提出来之时，几乎没有人能够理解。经过作者多次简化，再解释，包括谷歌等团队的实践再创造，再解释的过程，十几年过去了，才渐渐的成为事实标准并被大家所了解和接受。但直到现在，无比抽象的 Paxos 算法，还是没有几个人能理解。
大道至简!这是永恒不变的真理， Raft 的目标问题，是构建一个容易理解和构建的分布式一致性协议，在容易的基础上，确保理论正确的。
Raft 协议，如果照本宣读，还是需要点时间的，本文采用通俗的办法给大家做解释
Raft 大致的原理，这是一个选主( leader selection )思想的算法，集群总每个节点都有三种可能的角色：
( 1 ) leader
对客户端通信的入口，对内数据同步的发起者，一个集群通常只有一个 leader 节点
( 2 ) follower:
非 leader 的节点，被动的接受来自 leader 的数据请求
( 3 ) candidate:
一种临时的角色，只存在于 leader 的选举阶段，某个节点想要变成 leader ，那么就发起投票请求，同时自己变成 candidate 。如果选举成功，则变为 candidate ，否则退回为 follower 。