2PC两阶段提交协议
顾名思义：分为两个阶段：Prepare和Commit
Prepare：提交事务请求
- 询问 协调者向所有参与者发送事务请求，询问是否可执行事务操作，然后等待各个参与者的响应。
- 执行 各个参与者接收到协调者事务请求后，执行事务操作(例如更新一个关系型数据库表中的记录)，并将
Undo 和 Redo 信息记录事务日志中。 - 响应 如果参与者成功执行了事务并写入 Undo 和 Redo 信息，则向协调者返回 YES 响应，否则返回 NO
响应。当然，参与者也可能宕机，从而不会返回响应
Commit：执行事务提交
- commit 请求 协调者向所有参与者发送 Commit 请求。
图灵课堂 - 事务提交 参与者收到 Commit 请求后，执行事务提交，提交完成后释放事务执行期占用的所有资源。
- 反馈结果 参与者执行事务提交后向协调者发送 Ack 响应。
- 完成事务 接收到所有参与者的 Ack 响应后，完成事务提交。
中断事务
在执行 Prepare 步骤过程中，如果某些参与者执行事务失败、宕机或与协调者之间的网络中断，那么协调者就无法
收到所有参与者的 YES 响应，或者某个参与者返回了 No 响应，此时，协调者就会进入回退流程，对事务进行回
退。流程如下图红色部分(将 Commit 请求替换为红色的 Rollback 请求)：
2PC存在的问题
1.?同步阻塞?参与者在等待协调者的指令时，其实是在等待其他参与者的响应，在此过程中，参与者是无法进
行其他操作的，也就是阻塞了其运行。?倘若参与者与协调者之间网络异常导致参与者一直收不到协调者信
息，那么会导致参与者一直阻塞下去。
2.?单点?在?2PC?中，一切请求都来自协调者，所以协调者的地位是至关重要的，如果协调者宕机，那么就会
使参与者一直阻塞并一直占用事务资源。
如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服
务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息(例如已等待?Prepare?响应的时长
等)，所以也无法顺利处理上一个事务。
3.?数据不一致?Commit?事务过程中?Commit?请求/Rollback?请求可能因为协调者宕机或协调者与参与者网
络问题丢失，那么就导致了部分参与者没有收到?Commit/Rollback?请求，而其他参与者则正常收到执行了?
Commit/Rollback?操作，没有收到请求的参与者则继续阻塞。这时，参与者之间的数据就不再一致了。
当参与者执行?Commit/Rollback?后会向协调者发送?Ack，然而协调者不论是否收到所有的参与者的?Ack，该事务
也不会再有其他补救措施了，协调者能做的也就是等待超时后像事务发起者返回一个“我不确定该事务是否成
图灵课堂
功”。
4.?环境可靠性依赖?协调者?Prepare?请求发出后，等待响应，然而如果有参与者宕机或与协调者之间的网络
中断，都会导致协调者无法收到所有参与者的响应，那么在?2PC?中，协调者会等待一定时间，然后超时后，
会触发事务中断，在这个过程中，协调者和所有其他参与者都是出于阻塞的。这种机制对网络问题常见的现
实环境来说太苛刻了。