在分布式事务解决方案中也有自己的规则和协议，通常是2PC、3PC协议，由于3PC协议在实际的实现中很难实现，所以在当下的商业解决方案中都是基于2PC协议来实现分布式事务的解决方案的。
二阶段提交分为Prepare和Commit两个阶段。下面我们分别就这样两个阶段做详细说明。
Prepare阶段（提交事务请求）
在二阶段的提交中，第一阶段我们成为Prepare阶段，上图反应了其执行的流程。
询问：事务协调者向所有的事务参与者发送事务请求，询问是否可能知行事务，然后等待各个事务参与者的响应。
执行：各个事务参与者在接收到事务协调者的请求后，开始执行事务操作，并将undo、redo信息记录到事务日志中去。
响应：如果参与者成功执行了事务并记录了undo、redo日志，则向事务协调者返回YES，否则返回NO，当然了在实际中也可能存在参与者宕机就一直得不到响应的情况。
Commit阶段（执行事务提交）
这一阶段有两种情况，成功了执行commit，失败执行rollback。
现在我们先看看执行成功，执行事务commit的情况。先看流程图。
commit请求：事务协调者向所有的事务参与者发送事务commit请求。
所有的事务参与者在接收到协调者的请求后，执行事务提交操作，执行完成后释放在事务执行期间占用的系统资源。
反馈结果：参与者执行完事务提交后向协调者发送Ack响应。
完成事务：协调者在接收到所有事务参与者的Ack响应后完成事务提交。
接下来看看事务rollback回滚。
在执行Prepare阶段，难免的可能会出现如下情况：
参与者执行事务失败
参与者服务宕机
协调者与参与者网络通信中断
如果出行以上情况，这时协调者就无法接收到参与者的YES响应或者某一个参与者返回了NO响应，这时协调者就进入到了事务rollback回滚阶段，对事务进行回滚操作。下面是事务rollback回滚流程图。
rollback请求：事务协调者向所有的事务参与者发送事务rollback回滚请求。
参与者在接收到协调者的rollback回滚操作后，会根据在Prepare阶段记录的undo日志进行事务回滚，完成事务回滚后会释放掉在事务回滚执行期间占用的所有资源。
结果反馈：参与者完成事务rollback回滚后会向协调者发送Ack响应。
完成事务：事务协调者在接收到所有事务参与者的Ack响应后完成事务rollback回滚。
一篇文章要将分布式事务所有的知识点都讲到肯定是不现实的，为了让大家更加全面的学习分布式事务知识，特向大家推荐一本个人在学习分布式事务时使用的一本书，希望对大家有用，一起学习，共勉之！
深入理解分布式事务 原理与实战京东好评率100%无理由退换¥89.15购买
两阶段提交协议产生的问题
同步阻塞：在参与者等待协调者的指令的时候，实质上是在等待参与者的响应，在这期间参与者就不能进行任何其他的操作，也就是阻塞了其运行。如果发生了协调者与参与者不能进行网络通信的情况，参与者一直接收不到协调者的指令，那么参与者将会一直阻塞下去。
单点：在2PC中，一切请求都来自协调者，所以协调者的地位是至关重要的，如果协调者宕机，那么就会使参与者一直阻塞并一直占用资源。如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息（例如已等待Prepare响应的时长等），所以也无法顺利处理上一个事务。
数据不一致：Commit事务过程中，Commit/Rallback请求可能因为协调者宕机或协调者与参与者网络问题丢失，那么就导致了部分参与者没有收到Commit/Rallback请求，而其他参与者则正常收到执行了Commit/Rallback操作，没有收到请求的参与者继续阻塞。这时参与者之间的数据就不再一致了。
环境可靠性依赖：协调者Prepare请求发出后，等待响应，然而如果有参与者宕机或与协调者之间的网络中断，都会导致协调者无法收到所有参与者的响应，那么在2PC中，协调者会等待一定时间，然后超时后，会触发事务回滚。在这个过程中，协调者和所有参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。