1. 背景：
初时提出，是为解决分布式数据库的事务问题。单机数据库事务可靠日志技术，MVCC技术实现。分布式情况下，就需要额外的手段来保证，这才出现了二阶段提交。
2. 流程：
从角色上，二阶段提交分为两种角色：协调者(coordinate)，参与者(participant)。流程思路上很简单：
1. 协调者询问询问所有参与者，能否提交；参与者返回是否能提交的结果；
2. 协调者根据参与者的返回结果决定是否提交事务，并通知参与者执行。
但实际上，二阶段提交需要考虑不少异常场景：
对照上图：
1 宕机类：
协调者宕机：起来后，看本地日志。
如果在begin_commit，则发送prepare。即使参与者已经发送过了响应，也不影响。流程正常。
如果在global_commit或global_abort，则重新发送global-commit或global-abort。（如果参与者已经提交过，怎么办）。
如果协调者起不来，起新的协调者，向参与者取状态。如有commit的，则继续commit，否则abort。
参与者宕机：起来后，看本地日志。
如果在init，则等prepare。如果协调者已经发过，会超时，见下。
如果在ready日志，则按流程发送vote-commit继续往下走。
如果在abort或commit日志处，则什么都不干，等协调者重发。
2 等待响应超时类
大体来说，一阶段超时直接退出流程，二阶段超时持续重试。
协调者超时：
等待参与者对prepare响应超时（已收到全为vote-commit，但仍有未响应的参与者）。这时，直接放弃，发送global_abort。
等待global-commit或global-abort的响应超时。这时，无他法，只有不断重试。这可能会引起参与者重复提交。
参与者超时：
init后，在prepare等待处超时。直接进入abort。后面即使收到prepare，流程仍然正确。
确认可以提交后，在等待协调者二阶段命令时超时。说明已经发过vote_commit，由于不知道流程状态，只能不断重发vote_commit。
二阶段协议应用较少，理论价值大于实践价值。