之前的文章《分布式事务，原来可以这么玩?》引起了很大的讨论，打算以后开一个新的系列，讲分布式的东西。今天先从比较通俗易懂的“两阶段提交”说起。画外音：我给自己定了一个目标，用通俗易懂的语言理解Paxos。分布式事务为什么难？在分布式环境中，每个节点都可以知道自己操作的成功或失败，但无法知道其他节点操作的成功或失败。当分布式事务跨越多个节点时，很难保持事务的原子性和一致性。什么是两阶段提交？两阶段提交2PC（TwophaseCommit）是一种在分布式环境中所有节点提交事务并保持一致性的算法。它引入了一个协调器（Coordinator）来统一控制所有参与者（Participants）的操作结果，并指示它们是实际提交（commit）还是??回滚（rollback）操作结果。为什么叫两阶段提交？顾名思义，2PC分为两个阶段：投票阶段：参与者通知协调者，协调者反馈结果；画外音：trx.exec()可以理解为一个独立的事务。提交阶段：协调器收到参与者的反馈后，向参与者发送通知，并根据反馈决定每个参与者是要提交还是回滚；画外音：可以理解为trx.commit()或trx.rollback()。举个栗子：A、B、C、D要组织一次会议，他们需要确定会议时间。设A为协调者，B、C、D为参与者。投票阶段（1）A发邮件给B、B、D，通知明天10:00有会议，询问是否有时间；(2)B有时间回复；(3)C有时间回复；(4)D长时间不回复，此时对于这笔交易，A、B、C都处于阻塞状态，算法无法继续；在提交阶段（1），协调者A将收集到的结果通知B、C、D；voiceover：什么时候通知，反馈结果如何，这里取决于WithD的时间和决定，如果D的回复有时间，则通知commit；如果D的回复没有时间，则通知回滚；(2)B收到通知，并确认协调器；(3)C收到通知，ackCoordinator；(4)D收到通知并确认协调器；画外音：如果A没有收到所有的ack，分布式事务很长时间不会结束，下一轮投票也很长时间不会开始。两阶段提交的缺陷？2PC执行过程中，所有节点都处于阻塞状态，所有节点持有的资源（如数据库数据、本地文件等）都处于阻塞状态。典型的情况是：在某个参与者回复消息之前，所有参与者和协调者都处于阻塞状态；在协调者发送消息之前，所有参与者都处于阻塞状态；另外，如果出现协调者或者某个参与者，为了防止整个算法处于完全阻塞状态，往往需要使用超时机制来继续推进算法。总的来说，2PC是一个比较保守和低效的算法，分布式事务真的很难做。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
