该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：
场景一执行事务提交：
① 发送提交请求：进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求 。
② 事务提交：参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源 。
③ 反馈事务提交结果：参与者在完成事务提交后，向协调者发送Ack响应 。
④ 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务 。
场景二中断事务
① 发送中断请求：协调者向所有的参与者节点发送abort请求 。
② 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源 。
③ 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息 。
④ 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务 。
注意一旦进入阶段三，可能会出现 2 种故障：
1. 协调者出现问题
2. 协调者和参与者之间的网络故障
如果出现了任何一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针 这种情
况，参与者都会在等待超时之后，继续进行事务提交 。
1.8.3 2PC与3PC对比1、首先对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源 。而这种机制也侧面降低了整个事务的阻塞时间和范围 。
2、通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。
3、PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的 。但是3PC协议并没有完全解决数据不一致问题 。
推荐阅读
- win7桌面文件路径修改-win7系统桌面文件路径修改-
- win7系统如何关闭UAC功能控制的问题
- 新手教程，Linux系统下MySQL的安装
- 十分钟搞定分布式一致性算法
- 分布式数据之缓存技术，今天就一起来揭开其神秘面纱
- 让重装系统更简单：无需使用U盘，3分钟带你体验“云重装”
- 开源NAS系统OpenMediaVault安装与体验
- 七氟丙烷气体灭火系统要求?七氟丙烷灭火系统设置要求
- Go语言实现海量日志收集系统
- 每个软件架构师和软件工程师都必须知道的10种设计模式