网站数字化建设,龙岩天宫山简介概况,好公司网站建设,网站建设合作方案2PC协议就是两阶段提交#xff0c;用来解决分布式事务#xff0c;分为两个阶段#xff0c;分别为Prepare和Commit#xff0c;也是PC由来。
第一阶段Prepare 提交事务请求 如图所示#xff0c;主要流程有以下三个方面 询问#xff1a;事务协调者(Manager)向所有的事务参与…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中协调者会等待一定时间然后超时后会触发事务回滚。在这个过程中协调者和所有参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。
