二阶段提交

二阶段提交（2 Phase Commitment Protocol）：
为了使分布式系统架构下的各个节点在进行事务提交时保持一致性的一种协议。二阶段提交通过协调者和各个参与者的配合，实现分布式一致性。

角色

1. 协调者：调度事务
2. 参与者：参与事务的执行和投票

第一阶段：投票阶段。
协调者向所有的参与者节点询问是否可以执行提交操作，并开始等待各参与节点的响应；
参与者执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入事务日志（但是不提交事务）。如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息，如果参与者节点的事务实际执行失败，则它返回一个"中止"消息；

第二阶段：提交阶段
当协调者从所有的参与者节点获得的相应消息都是"同意"时：
1).协调者节点向所有参与者节点发出"正式提交(commit)"的请求
2).参与者正式完成操作，并释放在整个事务期间占用的资源
3).参与者节点向协调者节点发送"ack完成"消息
4).协调者收到所有参与者节点反馈的"ack完成"消息后，完成事务

如果任一参与者节点在第一阶段返回的信息是"中止"，或者协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应信息时，那么这个事务就会被回滚：
1).协调者节点向所有参与者节点发出"回滚操作(rollback)"的请求
2).参与者节点利用之前的Undo信息执行回滚，并释放在整个事务期间占用的资源
3).参与者节点向协调者节点发送"ack回滚完成"信息
4).协调者节点收到所有参与者节点反馈的"ack回滚完成"信息后，取消事务

不管最后结果如何，第二阶段都会结束当前事务。

2 PC存在的问题：

1. 性能问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2. 可靠性问题：参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。
3. 数据一致性问题：二阶段无法解决的问题：协调者在发出
   commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

2PC的优点：
尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）