两阶段提交引入原因与基本流程

赵星宇

1.引入原因

我们设想一个A,B,C,D约时间打麻将的场景，其中A是组织者。

一阶段情况下：A直接发短信给B,C,D，跟大家说今晚打麻将，大家过来吧。假设B没回复或回复来不了时，A也不会继续通知大家，势必造成C,D两个人白跑一趟。

两阶段情况下：首先A给B,C,D发短信，约大家打麻将，询问大家是否都能参加。

情况1：B,C,D中有人回复不能参加或者没有回复，因为不够四个人，所以A会继续发短信通知所有人今晚因为人不够，大家都别来了，等所有人回复后，A确定取消。

情况2：B,C,D所有人都回复能参加，因为够了四个人，所以A会继续发短信通知所有人今晚人够了，大家都准时过来，等所有人回复后，A确定今晚打麻将。

对于数据库分布式事务提交来说，一个事务可能涉及多个节点，如果这个事务在有的节点中无法完成，这时需要所有节点rollback，如果这个事务在所有节点都可以完成，这时需要所有节点commit。在一阶段情况下，有节点commit成功，有节点commit失败，而已经commit成功的节点则无法rollback了。因此在在分布式事务中必须使用两阶段提交，首先确定每一个节点都可以commit时，才告诉所有节点commit，否则告诉所有节点rollback。

2.基本流程

角色：

协调者（Coordinator），即上面例子中的A，其只能有一个。

参与者（Participant），即上面例子中的B,C,D。

阶段：

prepare阶段：协调者通知所有参与者将要进行的操作，询问是否可以完成，等待所有参与者应答。

commit阶段：协调者通知所有参与者将要进行的操作是否打算进行，等待所有参与者应答。

过程：

如下图，注意：在图中没有画出协调者返回客户端成功或失败的时机，那个时机应该是收到所有参与者commit阶段的回复之后。

注：图片来自网络，侵删