1、二阶段提交协议：
二阶段协议分为两步，分别是投票阶段、提交阶段。
- 投票阶段：事务提议的协调者向所有参与者发出事务请求，参与者记录事务日志，并返回ok；或者事务不可执行，返回fail。
- 提交阶段：协调者收到参与者的ack后，发出提交请求，参与者收到后执行事务，并返回ack。若收到参与者返回的fail消息或者等待参与者确认消息超时，协调者发出rollback消息，所有参与者执行事务回滚。
- 存在问题：若在回滚过程中或提交过程中协调者宕机，那么只有部分参与者收到回滚消息或提交消息，这将导致系统消息不一致。整个过程中协调者、参与者都在阻塞等待，性能较低。协调者存在单点问题。
2、三阶段提交协议
三阶段提交协议相比二阶段提交协议多了一个询问步骤，并且参与者在完成写事务日志发出确认消息后，若没有收到提交消息将自动执行提交。
- 询问阶段：协调者向所有参与者发出事务询问请求，参与者返回确认消息ok。
- preCommit阶段：协调者向参与者发送事务，参与者写事务日志，返回ack。
- commit阶段：协调者收到确认消息后，向所有参与者发送commit消息，所有参与者执行事务，返回ack。
- 相比二阶段提交改进：减少了事务的等待过程。解决了协调者单点问题。
- 存在问题：与二阶段提交相似，若在preCommit阶段出现网络问题，那么没有收到提交请求的参与者将自动提交事务，此时协调者可能正在回滚事务，将导致事务一致性问题。
3、paxos协议
paxos提出提出了“过半数”有效的概念，即超过半数节点存在就能正常提供服务。
- 针对二阶段、三阶段提交协议的一致性问题：
paxos为每个提议增加了递增的编号m，编号越大说明提议越新，系统应该以最新的提议编号为最终一致性值。
提议的流程分为prepare和accept两阶段：
1、协调者生成增长的编号m，向所有参与者发送prepare（m）。
2、参与者若接收过提议，则返回已接收的所有提议编号最大值m‘和提议内容v‘；若没有接收过提议则返回空表示接收提议。
3、协调者若收到参与则通过数据超过一半则进入accept阶段，否则从返回结果中选出最大值m’并更新提议内容v’，使用更新后的提议（m‘，v’）返回步骤1。
4、协调者进入accept阶段后，发送accept（m，v）。
5、参与者需要判断提议编号m，若m大等于自己记录的值则通过提议，返回ok；否者不接受提议，返回对应编号和内容（m‘，v’）。
6、提议者根据步骤5结果判断通过数量是否超过一半，超过则表示提议通过；否从返回值中选出最大m‘并更新v‘，返回步骤1。
这个算法流程怎么实现一致性的？
综合上述流程，通过参与者的不断比对反馈，最终只有一个提议会被超过半数的参与者通过，可以确定在进行中的提议都会最终达成一致，并更新到所有参与者中去。
另外，当出现更大编号提议时，协调者需要更新提议重复发出提议，如果更大编号被不断提出，那么可能使得协议一直不能达成一致，这就导致活锁问题。
参考：
- 《从paxos到zookeeper》
- https://www.zhihu.com/question/19787937
