2.1 2PC中的参与者故障让我们考虑几种故障的场景。例如，如图13-2所示，如果其中一个参与者在提议阶段故障，则协调者无法继续进行提交，因为它要求所有投票都是赞成票。如果其中一个参与者不可用，则协调者将中止事务。该要求会影响到可用性：单个节点的故障就会阻止事务提交。一些系统，例如Spanner（参见13.5节），在Paxos组而不是单个节点上执行2PC，从而改进可用性。
2PC的核心思想在于参与者的承诺：一旦对提案做出了肯定的回应，它不能再反悔，因此只有协调者才能中止事务。 如果其中一个参与者在接受提案后发生故障，它必须先了解投票的实际结果，然后才能知道正确的值，因为协调者可能由于其他参与者的投票而中止了提交。当参与者节点恢复时，它必须跟上协调者的最终决定。为此，我们通常将决策日志保留在协调者端，并将决定的值复制到故障的参与者。在此之前，参与者不能处理请求，因为它还处于不一致状态。由于协议中存在多个阻塞操作，此时进程要等待其他参与者（当协调者收集投票时，或参与者正在等待提交/中止阶段时），因此，链路故障可能导致消息丢失，进程会无限地等待下去。如果提议阶段中协调者未收到来自某个副本的响应，它不会因此阻塞，因为它可以触发超时并中止事务。
2.2 2PC中的协调者故障
第二阶段中，如图13-3所示，如果某个参与者没有收到协调者的提交或中止指令，则应当尝试找出协调者做出的决定。协调者可能已经决定了该值，但未能传达给某个副本。在这种情况下，可以从其他参与者的事务日志或是备份协调者的日志中找到决策信息。从复制日志中确定提交决定是安全的，因为这个决定一定是已经达成一致的：2PC的最终目的就是在所有节点上提交或中止，在一个参与者中提交即意味着其他所有参与者都必须提交。第一阶段中，协调者收集投票，继而也就获得了参与者的承诺：它们将等待其明确的提交或中止指令。如果协调者在收集投票后、广播投票结果之前发生故障，则参与者最终将处于不确定状态。如图13-4所示，参与者不知道协调者的决定，也不知道它是否已向某些参与者（可能也不可达）通知了事务结果[BERNSTEIN87]。
协调者无法继续进行提交或中止操作，这使得集群处于未决状态。这意味着在发生协调者永久性故障的情况下，参与者将无法得知最终决定。因为这个特性，我们说2PC是一种阻塞原子提交算法。如果协调者始终无法恢复，它的替代者只能再次为给定事务收集投票，并做出最终决定。许多数据库使用2PC：MySQL、PostgreSQL、MongoDB注2等。因为其简单性（易于论证、实现和调试）和低开销（消息复杂度和协议往返次数低），两阶段提交经常用于实现分布式事务。实现正确的恢复机制并拥有备份协调者节点，以减少发生上述故障的可能性，这一点非常重要。
3 三阶段提交
为了让原子提交协议在协调者故障下保持健壮并避免进入未决状态，三阶段提交（3PC）协议增加了一个额外的步骤，并且双方都具有超时机制，使得参与者在协调者发生故障时仍能继续提交或中止（取决于系统状态）。3PC假定同步网络模型，且不存在通信故障[BABAOGLU93]。3PC在提交/中止步骤之前添加了一个准备阶段，该阶段中协调者告知参与者在提议阶段收集的投票信息，即使协调者发生故障，协议也可以继续执行。3PC的所有其他性质都和2PC类似，包括要求有一个协调者。3PC的另一个有用的补充是参与者侧的超时，参与者根据进程当前正在执行的步骤，超时之时将强制进行提交或中止。如图13-5所示，三阶段提交包含以下三个步骤：
提议（propose）阶段 协调者发出提议值并收集投票。
准备（prepare）阶段 协调者将投票结果通知参与者。如果投票通过并且所有参与者都决定要提交，则协调者会发送一条Prepare消息，指示它们准备提交。否则，将发送Abort消息并退出流程。
提交（commit）阶段 协调者通知参与者提交事务。
在提议这一步中，类似于2PC，协调者分发提议值并收集参与者的投票，如图13-5 所示。如果协调者在此阶段崩溃导致操作超时，或者其中一个参与者投反对票，则事务中止。
收集投票后，协调者做出决定。如果协调者决定继续进行事务，则发出Prepare指令。协调者可能无法将Prepare消息发送给所有参与者，或是可能没有收到参与者的确认。这种情况下，参与者可能会在超时后中止事务，因为算法尚未完全进入到已准备状态。
一旦所有参与者成功进入已准备状态并且协调者收到了它们的准备确认，无论其中任何一方发生故障，事务都将被提交。之所以可以这样做是因为此阶段中所有参与者看到的状态是相同的。
在提交阶段，协调者将准备阶段的结果传达给所有参与者，重置它们的超时计数器并完成事务。
