二阶段提交、三阶段提交、paxos协议

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。

这个算法流程怎么实现一致性的？
综合上述流程，通过参与者的不断比对反馈，最终只有一个提议会被超过半数的参与者通过，可以确定在进行中的提议都会最终达成一致，并更新到所有参与者中去。
另外，当出现更大编号提议时，协调者需要更新提议重复发出提议，如果更大编号被不断提出，那么可能使得协议一直不能达成一致，这就导致活锁问题。

参考：

1. 《从paxos到zookeeper》
2. https://www.zhihu.com/question/19787937