摘要:以两阶段提交来说,主持人收到一个提案请求,打电话跟每个组员询问是否通过并统计回复,然后将最后决定打电话通知各组员。三阶段提交即是引入了另一个步骤,主持人打电话跟组员通知请准备通过提案,以避免没人知道真实决定而造成决定不一致的失业危机。
3PC
以两阶段提交来说,主持人收到一个提案请求,打电话跟每个组员询问是否通过并统计回复,然后将最后决定打电话通知各组员。要是主持人在跟第一位组员通完电话后失忆,而第一位组员在得知结果并执行后老人痴呆,那么即使重新选出主持人,也没人知道最后的提案决定是什么,也许是通过,也许是驳回,不管大家选择哪一种决定,都有可能与第一位组员已执行过的真实决定不一致,老板就会不开心认为决策小组沟通有问题而解雇。三阶段提交即是引入了另一个步骤,主持人打电话跟组员通知请准备通过提案,以避免没人知道真实决定而造成决定不一致的失业危机。为什么能够解决二阶段提交的问题呢?回到刚刚提到的状况,在主持人通知完第一位组员请准备通过后两人意外失忆,即使没人知道全体在第一阶段的决定为何,全体决策组员仍可以重新协调过程或直接否决,不会有不一致决定而失业。那么当主持人通知完全体组员请准备通过并得到大家的再次确定后进入第三阶段,当主持人通知第一位组员请通过提案后两人意外失忆,这时候其他组员再重新选出主持人后,仍可以知道目前至少是处于准备通过提案阶段,表示第一阶段大家都已经决定要通过了,此时便可以直接通过 --------
以上资料来自wiki百科,说明在2PC过程中,在第二个阶段当协调者通知第一个客户端A,并且第一个客户端刚好执行完毕以后,这两台机器都Down掉了,而恰好这N-1台机器投的都是Yes票(都处于不确定的状态),这个时候整个事务就会被Block,暂时称之为聋哑事件
客户端A投的是Abort票,那么由于协调者和客户端A都Down掉,那么整个事务应该是abort
客户端A投的是commit票,并且协调者决定commit,那么整个事务应该是commit
客户端A投的是commit票,并且协调者由于自身的原因决定abort,那么整个事务应该是abort
在3PC中引入了一个预提交的状态
当在第二阶段出现聋哑事件,那么这N-1台机器可以根据超时机制直接abort掉,因为客户端A如果提交了事务,只是预提交,当该机器重启以后只要询问周边机器事务状态,简单的将事务回滚或者提交事务,就能保持事务的最终一致性
当进行到第三阶段的时候,如果发生聋哑事件,那么其它处于「不确定状态」的客户端会直接执行commit,而不会像2PC一样导致事务block,但是这样会有一个风险(进入到第三个阶段说明客户端在第一阶段投的都是Yes),因为在聋哑事件中,那台Down掉的机器在第二阶段中给协调者发送的不是prepared,这个时候协调者收到消息给客户端发送的是abort命令.所以3PC只是乐观的认为只要你第一阶段大家投的都是Yes,那么最后成功提交的几率很大
关于分布式事务、两阶段提交协议、三阶提交协议
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/21404.html
摘要:以两阶段提交来说,主持人收到一个提案请求,打电话跟每个组员询问是否通过并统计回复,然后将最后决定打电话通知各组员。三阶段提交即是引入了另一个步骤,主持人打电话跟组员通知请准备通过提案,以避免没人知道真实决定而造成决定不一致的失业危机。 3PC 以两阶段提交来说,主持人收到一个提案请求,打电话跟每个组员询问是否通过并统计回复,然后将最后决定打电话通知各组员。要是主持人在跟第一位组员通完电...
摘要:最终一致性二基于的分布式事务补偿机制序列图异常场景处理预创建订单失败如果实际预创建订单成功订单定时补偿机制定时删除这部分订单不影响数据一致性下单失败预扣减库存失败如果预扣减库存真实失败则下单失败订单由定时补偿机制定时删除其它应用参照场景的处 最终一致性(二) 基于MQ的分布式事务补偿机制 序列图 showImg(https://segmentfault.com/img/bVzeHX);...
摘要:最终一致性二基于的分布式事务补偿机制序列图异常场景处理预创建订单失败如果实际预创建订单成功订单定时补偿机制定时删除这部分订单不影响数据一致性下单失败预扣减库存失败如果预扣减库存真实失败则下单失败订单由定时补偿机制定时删除其它应用参照场景的处 最终一致性(二) 基于MQ的分布式事务补偿机制 序列图 showImg(/img/bVzeHX); 异常场景处理 预创建订单失败:如果实际预创建...
摘要:如上图所示,的实际上是已中间件的形式放在应用层,不用依赖数据库对协议的支持,完全剥离了分布式事务方案对数据库在协议支持上的要求。 微信公众号「后端进阶」,专注后端技术分享:Java、Golang、WEB框架、分布式中间件、服务治理等等。 在微服务架构体系下,我们可以按照业务模块分层设计,单独部署,减轻了服务部署压力,也解耦了业务的耦合,避免了应用逐渐变成一个庞然怪物,从而可以轻松扩展,...
摘要:最终一致性一简介是由支付宝架构师提供的一种柔性解决分布式事务解决方案主要包括三个步骤流程的关键流程如下图以下单和扣减库存为例子预生成订单失败了为什么要通过执行预处理数据回滚可能预生成订单成功但是接口返回失败超时失败所以预处理在某些情况下是有 最终一致性(一) TCC 简介 TCC是由支付宝架构师提供的一种柔性解决分布式事务解决方案,主要包括三个步骤:showImg(/img/bVzc6...
阅读 3642·2021-11-15 11:37
阅读 2310·2021-09-24 10:39
阅读 2424·2021-07-25 21:37
阅读 1404·2019-08-30 15:56
阅读 2575·2019-08-30 15:55
阅读 944·2019-08-30 15:54
阅读 2117·2019-08-30 14:21
阅读 847·2019-08-30 11:24