2PC协议就是两阶段提交,用来解决分布式事务,分为两个阶段,分别为Prepare和Commit,也是PC由来。
第一阶段Prepare 提交事务请求
如图所示,主要流程有以下三个方面
-
询问:事务协调者(Manager)向所有的事务参与者发送事务请求,询问是否可能执行事务,然后等待各个待各个事务参与者的响应。
-
执行:各个事务参与者在接收到事务协调者的请求后,开始执行事务操作,并将undo、redo信息记录到事务日志中去。
-
响应:如果参与者成功执行了事务并记录了undo、redo日志,则向事务协调者返回YES,否则返回NO,当然了在实际中也可能存在参与者宕机就一直得不到响应的情况。
第二阶段Commit 执行事务提交
两种情况,一种是成功执行commit,另一种是执行失败rollback
执行成功commit,流程图
-
commit请求:事务协调者向所有的事务参与者发送事务commit请求。所有的事务参与者在接收到协调者的请求后,执行事务提交操作,执行完成后释放在事务执行期间占用的系统资源。
-
反馈结果:参与者执行完事务提交后向协调者发送Ack响应。
-
完成事务:协调者在接收到所有事务参与者的Ack响应后完成事务提交。
执行失败rollback
在执行Prepare阶段,难免的可能会出现如下情况:
-
参与者执行事务失败
-
参与者服务宕机
-
协调者与参与者网络通信中断
如果出行以上情况,这时协调者就无法接收到参与者的YES响应或者某一个参与者返回了NO响应,这时协调者就进入到了事务rollback回滚阶段,对事务进行回滚操作。如下图
-
rollback请求:事务协调者向所有的事务参与者发送事务rollback回滚请求。
-
参与者在接收到协调者的rollback回滚操作后,会根据在Prepare阶段记录的undo日志进行事务回滚,完成事务回滚后会释放掉在事务回滚执行期间占用的所有资源。
-
结果反馈:参与者完成事务rollback回滚后会向协调者发送Ack响应。
-
完成事务:事务协调者在接收到所有事务参与者的Ack响应后完成事务rollback回滚。
可能存在的问题
-
同步阻塞:在参与者等待协调者的指令的时候,实质上是在等待参与者的响应,在这期间参与者就不能进行任何其他的操作,也就是阻塞了其运行。如果发生了协调者与参与者不能进行网络通信的情况,参与者一直接收不到协调者的指令,那么参与者将会一直阻塞下去。
-
单点:在2PC中,一切请求都来自协调者,所以协调者的地位是至关重要的,如果协调者宕机,那么就会使参与者一直阻塞并一直占用资源。如果协调者也是分布式,使用选主方式提供服务,那么在一个协调者挂掉后,可以选取另一个协调者继续后续的服务,可以解决单点问题。但是,新协调者无法知道上一个事务的全部状态信息(例如已等待Prepare响应的时长等),所以也无法顺利处理上一个事务。
-
**数据不一致:**Commit事务过程中,Commit/Rallback请求可能因为协调者宕机或协调者与参与者网络问题丢失,那么就导致了部分参与者没有收到Commit/Rallback请求,而其他参与者则正常收到执行了Commit/Rallback操作,没有收到请求的参与者继续阻塞。这时参与者之间的数据就不再一致了。
-
**环境可靠性依赖:**协调者Prepare请求发出后,等待响应,然而如果有参与者宕机或与协调者之间的网络中断,都会导致协调者无法收到所有参与者的响应,那么在2PC中,协调者会等待一定时间,然后超时后,会触发事务回滚。在这个过程中,协调者和所有参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。