一、两段式
1、请求阶段（commit-request phase，或称表决阶段，voting phase）
事务询问。协调者向所有参与者发送事务内容，询问是否可以进行事务提交操作，然后就开始等待参与者的响应。
执行事务。各参与者节点执行事务操作（本地事务），并将Undo和Redo信息记入事务日志中。
各参与者向协调者反馈事务询问的响应。同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
2、提交阶段（commit phase）
在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。
当且仅当所有的参与者同意提交，事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者回滚事务。
两段式的缺点
1、同步阻塞问题。
执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2、单点故障
当协调者出错，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
3、
第二阶段当协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
4、数据不一致
在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求，而在这部分参与者接到commit请求之后就会执行commit操作，但是其他部分未接到commit请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据局部不一致性的现象。
二、三段式
1、CanCommit
事务询问。
各参与者向协调这反馈事务询问的响应。
2、PreCommit
假设协调者从所有的参与者获得的都是Yes响应，那么将执行事务预提交。执行事务操作，将Undo和Redo信息记录到事务日志中。
假设任何一个参与者向协调者反馈了No反应，或者在等待超时之后，协调者无法获得所有参与者的响应，那么将执行事务的中断。
3、doCommit
该阶段将进行事务提交，或者事务回滚。
三段式和两段式的区别
对于协调者(Coordinator)和参与者(Cohort)都设置了超时机制；
降低了参与者的阻塞范围，两段式在第一阶段就阻塞，而三段式在第二阶段阻塞；
解决了单点阻塞问题，因为一旦参与者无法及时收到来自协调者的信息之后，他会由于超时而默认执行commit。但如果协调者发送的是abort，而其中一个参与者因为网络问题没有收到，最终执行了commit，就会导致这个参与者与其他执行了abort的参与者数据不一致。
（使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。也就是说，即使当协调者发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，仍可以知道目前至少是处于准备通过提案阶段，表示第一阶段大家都已经决定要通过了，此时便可以直接通过。（也就是第一阶段的预通知起到了保障的作用））