阶段一:提交事务请求
- 1.事务询问:协调者向所有参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
- 2.执行事务:各个参与者结点执行事务操作，并将Undo和Redo的信息记入事务日志中。
- 各个参与者向协调者反馈事务询问的响应:如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可执行。
由于上面讲述的内容在形式上近似是协调者组织各参与者对一次事务操作的投票表态过程，因此二阶段提交协议的阶段一也称为“投票阶段”，即各个参与者投票表明是否要继续执行接下去的事务提交操作。
阶段二:执行事务提交
在阶段二中，协调者会根据各个参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下，包含以下两种可能。
执行事务提交
假设协调者从所有的参与者获得的反馈都是YES响应，那么就会执行事务提交。
- 1.发送提交请求:协调者向所有参与者结点发送Commit请求。
- 2.事务提交:参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
- 3.反馈事务提交结果:参与者在完成事务提交之后，向协调者发送Ack消息。
- 4完成事务.:协调者接收到所有参与者反馈的Ack消息后，完成事务。
中断事务
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。
- 1.发送回滚请求:协调者向所有参与者结点发送出Rollback请求。
- 2.事务回滚:参与者接收到Rollback请求后，会利用其在阶段一记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在事务执行期间占用的资源。
- 3.反馈事务回滚结果:参与者在完成事务回滚之后，向协调者发送Ack消息。
- 4.中断事务:协调者接收到所有参与者反馈的Ack消息后，完成事务中断。
在两阶段提交中，前后两个阶段分别进行处理逻辑。二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此可以将二阶段提交看做一个强一致性的算法。
优缺点
二阶段提交协议的优点:原理简单，实现方便
二阶段提交协议的缺点:同步阻塞，单点问题，脑裂，太过保守
- 同步阻塞:二阶段提交协议存在的最明显也是最大的一个问题就是同步阻塞，这会极大地限制分布式系统的性能。在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。
- 单点问题:协调者在这个过程中扮演重要角色。一旦协调者出现了问题，那么整个二阶段提交流程将无法运转，更为严重的是，如果协调者是在二阶段中出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。
- 数据不一致:在二阶段提交协议的阶段二，即执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求。于是，这部分收到了Commit请求的参与者就会进行整个事务提交，而其他没有收到Commit请求的参与者则无法进行事务提交，于是整个分布式系统便出现了数据不一致现象。
- 太过保守:如果在协调者知识参与者进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，这样的策略显得比较保守。换句话说说，二阶段提交协议没有涉及较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。