a) 两阶段提交协议(2PC)
系统包括两类节点：一个协调者和多个事务参与者，正常的执行过程中，这两个阶段的执行过程如下：
- 请求阶段：协调者通知事务参与者准备提交或者取消事务然后进入表决阶段，事务参与者告知协调者自己的决策：同意（事务参与者本地执行成功）或者取消（事务参与者本地执行失败）
- 提交阶段：协调者基于第一个阶段的投票结果进行决策。当且仅当所有参与者同意提交事务协调者才通知所有参与者提交事务
很明显，2PC存在两种故障：
- 事务参与者发生故障：给每个事务设置一个超时时间，如果某个事务参与者已知不响应，到达超时时间后整个事务失败
- 协调者发生故障：协调者需要将事务相关信息记录到操作日志并同步到备用协调者节点。如果没有备用协调点，那么事务参与者将已知等待下去。
可以知道，2PC是阻塞协议，执行过程需要锁住其他更新，且不能容错，大部分分布式存储系统并不采用该协议。
b) Paxos协议
为了实现高可用性，主节点往往将数据以操作日志的形式同步到备节点，如果主节点发生故障，备节点会提议自己成为主节点，在大多数系统中只有一个备节点提议，这时Paxos协议执行步骤如下：
- 批准(accept)：提议者发送accept消息要求所有其他节点(acceptor)接受这个提议值，acceptor可以选择接受或者拒绝
- 确认(acknowledge)：如果超过一半的acceptor接受了这个提议，意味着提议值生效，proposer发送acknowledge消息通知所有的acceptor提议生效
当出现网络或者其他异常的时候，系统中可能存在多个proposer，他们各自发起不同的提议。这里的提议可以是修改操作，也可以是提议自己成为主节点。如果proposer第一次发起的accept请求没有被acceptor中的多数派批准，那么需要执行一次完整的Paxos协议：
- 准备（prepare）：proposer首先选择一个提议序号n给其他的acceptor节点发送prepare消息。Acceptor收到prepare消息后如果提议的序号大于他已经回复的所有prepare消息，则acceptor将自己上次接受的提议回复给proposer，并承诺不再回复小于n的提议
- 批准（accept）：Proposer收到了acceptor中的多数派对prepare的回复后，就进入批准阶段。如果在之前的prepare阶段acceptor回复了上次接受的提议，那么proposer选择其中序号最大的提议值发给acceptor批准，否则，proposer生成一个新的提议值发给acceptor批准。Acceptor在不违背他之前在prepare阶段承诺的前提下，接受这个请求。
- 确认（acknowledge）：如果超过一般的acceptor接受，提议值生效。Proposer发送acknowledge消息通知所有的acceptor提议生效
有两个问题值得考虑，正确性（只有一个提议值生效）和可终止性（最后总有一个提议值生效）。Paxos协议中要求每个生效的提议被acceptor中的多数派接受，并且每个acceptor不会接受两个不同的提议，从而保证正确性。但是Paxos并不能保证严格的可终止性，但是从运行过程看，如果有超过一个acceptor接受了提议没那么proposer很快就会发现，并重新提议其中序号最大的提议值。因此，协议会往“提议值被多数派接受并生效”这一最终目标靠拢。
Paxos协议有两种用法，一是用来实现全局的锁服务或者命名和配置服务；二是将用户数据复制到多个数据中心。
c) Paxos和2PC的比较
所起作用不同：Paxos用于同一数据分片的多个副本之间的数据一致性，2PC用于保证属于多个数据分片上的操作的原子性。
2PC最大的问题是无法解决协调者宕机问题，通常可以将2PC和Paxos结合起来，使用Paxos选举新的协调者。