上一篇《分布式事务，原来可以这么玩?》引起了不少讨论，后续准备开一个新系列，讲一讲分布式的东西，今天就从相对容易理解的“两阶段提交”谈起。
画外音：给自己定了一个目标，用通俗的语言把Paxos讲懂。
分布式事务为什么难?
在分布式环境下，每个节点都可以知晓自己操作的成功或者失败，却无法知道其他节点操作的成功或失败。当一个分布式事务跨多个节点时，保持事务的原子性与一致性，是非常困难的。
什么是两阶段提交?
二阶段提交2PC(Two phase Commit)是一种，在分布式环境下，所有节点进行事务提交，保持一致性的算法。
它通过引入一个协调者(Coordinator)来统一掌控所有参与者(Participant)的操作结果，并指示它们是否要把操作结果进行真正的提交(commit)或者回滚(rollback)。
为什么叫两阶段提交?
顾名思义，2PC分为两个阶段：
- 投票阶段(voting phase)：参与者通知协调者，协调者反馈结果;
画外音：可以理解为单机事务的trx.exec()。
- 提交阶段(commit phase)：收到参与者的反馈后，协调者再向参与者发出通知，根据反馈情况决定各参与者是否要提交还是回滚;
画外音：可以理解为单机事务的trx.commit() 或者 trx.rollback()。
举个栗子：
甲乙丙丁四人要组织一个会议，需要确定会议时间，不妨设甲是协调者，乙丙丁是参与者。
投票阶段
(1)甲发邮件给乙丙丁，通知明天十点开会，询问是否有时间;
(2)乙回复有时间;
(3)丙回复有时间;
(4)丁迟迟不回复，此时对于这个事务，甲乙丙均处于阻塞状态，算法无法继续进行;
提交阶段
(1)协调者甲将收集到的结果通知给乙丙丁;
画外音：什么时候通知，以及反馈结果如何，在此例中取决与丁的时间与决定，
- 假设丁回复有时间，则通知commit;
- 假设丁回复没有时间，则通知rollback;
(2)乙收到通知，并ack协调者;
(3)丙收到通知，并ack协调者;
(4)丁收到通知，并ack协调者;
画外音：如果甲没有收到所有ack，则分布式事务迟迟不会结束，下一轮投票则迟迟不会开展。
两阶段提交的缺陷?
2PC在执行过程中，所有节点都处于阻塞状态，所有节点所持有的资源(例如数据库数据，本地文件等)都处于封锁状态。
典型情况为：
- 某一个参与者回复消息之前，所有参与者以及协调者都处于阻塞状态;
- 在协调者发出消息之前，所有参与者都处于阻塞状态;
另外，如有协调者或者某个参与者出现了崩溃，为了避免整个算法处于一个完全阻塞状态，往往需要借助超时机制来将算法继续向前推进。
总的来说，2PC是一种比较保守并且低效的算法，分布式事务真的很难做。
【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】
