2PC和3PC中故障情况分析
2PC故障情况分析
1. 协调者正常，参与者宕机
- 发生在第二阶段：无论协调者发起的是提交还是终止，那宕机的参与者在重启之后，都将执行对应操作，不存在不一致情况。
- 发生在第一阶段：由于协调者无法收集到所有参与者的反馈，会陷入阻塞情况。
解决办法：引入超时机制。
- 超过指定时间未收到反馈，事务失败，向所有节点发送终止事务请求。
- 宕机的节点启动后，收到终止事务请求，该事务失败。
小结
简单来说，由于协调者没挂，无论参与者是否宕机，都可以从协调者这里获取正确的状态。
2. 协调者宕机，参与者正常
无论处于哪个阶段，由于协调者宕机，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况。
解决办法：引入协调者备份，同时协调者需记录操作日志。
- 当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态。
- 如果存在commit或者abort，则对所有节点执行对应的操作。（是不会存在既有commit和abort的情况的）
- 如果只有prepare和未执行，可以继续完成该事务，也可以终止该事务。最终的状态是一致的。
小结
由于参与者正常，引入协调者备份和日志机制后，总能根据日志获取未完成的事务，并向各个参与者查询出对应的状态，并针对性的处理。
3. 协调者、参与者都发生了宕机
首先协调者宕机，那我们需要使用协调者备份，该协调者备份启动后，通过日志找到未完成的事务，对各参与者发起询问。由于参与者存在宕机，我们细分为以下3种情况：
- 存在commit或者abort，则执行对应操作。
- 存在未开始的节点，说明没有节点到第二阶段，可以直接终止。
- 剩下的情况就是：未宕机的节点都是prepare状态。这种情况最复杂，因为无法判断宕机节点的状态，它可能是commit、abort、prepare或者未开始。
下面具体分析第三种情况：
- 如果宕机节点是prepare或者未开始的话，则终止就可以了，这种情况没问题。
- 如果宕机节点是commit或者abort的话，由于该结点的事务已经结束，无法改变，所以对于其他节点必须执行相同的操作，否则就会不一致。但是你不知道该节点到底是什么状态，除非它重新启动了。
小结
出现第三种情况的话，由于无法判断事务状态，则无法完成该事务。该问题无法解决，只能等待参与者恢复，并确认参与者的状态。
3PC故障情况分析
2PC与3PC异同
- 2PC在第一阶段就执行对应操作了（资源被锁定），而第二阶段是提交。
- 3PC第一阶段只是询问能否提交，并不锁定资源；第二阶段再锁定资源执行对应操作；第三阶段是提交。
- 3PC如果第二阶段执行后，超过一定时间未收到协调者信息，会自动提交。
3PC的状态
- 处于第一阶段（CanCommit）：参与者返回YES、NO。
- 处于第二阶段（PreCommit）：协调者如果第一阶段存在NO或者超时则ABORT，如果全部是YES则PREPARE。参与者返回ACK。
- 处于第三阶段（doCommit）：协调者如果第二阶段存在NO或者超时则ABORT，如果全部是ACK则COMMIT。参与者返回ACK。
3PC故障情况分析
这里跳过只有协调者或者只有参与者宕机的情况，这2种情况的解决方案与2PC一致。直接讨论协调者、参与者都发生了宕机，为了简化，假设参与者只宕机了一台。
- 存在COMMIT、ABORT，执行对应操作
- 存在处于第一阶段或者未开始的节点，说明事务未进入第三阶段，直接终止。可能出现宕机节点处于第二阶段的情况，但无论宕机节点是abort或者prepare或者第一阶段或者未开始，都可以执行abort指令。
- 未宕机节点全是prepare状态。如果宕机参与者是PREPARE状态，重启后会收到COMMIT消息，这种没问题。如果是COMMIT状态，也没问题。如果是ABORT状态，由于其他节点变成了COMMIT，此时出现状态不一致。如果是宕机节点未收到PREPARE消息，也就是处于第一阶段完成后，这个时候他只可能是返回YES，重启后收到PREPARE和COMMIT消息后，状态也正确。
总结
我们可以发现3PC使用超时自动提交的方式解决了2PC中无法判断状态需要不断等待的情况，也就是提升了服务可用性。但是3PC比2PC多了一个步骤，所以延时应该是增加了。同时3PC可能存在网络分化情况，也就是协调者在第二阶段发送了PREPARE消息后，如果在第三阶段发送ABORT消息，则如果网络出现问题，导致消息部分节点未送达，就会出现某些节点ABORT了，某些节点COMMIT了。
也就是说，3PC实际并没有解决2PC中的那种协调者和参与者同时宕机的场景，只是做了自动提交，来提升服务可用性。
那2PC能否做自动提交呢？2PC由于只有2个阶段，第一阶段就已经执行对应的操作了（锁资源），如果没有收到第二阶段的COMMIT请求就自动提交，那连一次跟其他节点确认的机会都没有，这样出错的可能性很大。3PC至少是经过第一轮跟其他节点确认后，才会进行超时自动提交的，降低了出错概率。
综上，2PC延迟低，但是参与者故障后可能会阻塞；3PC可用性高，但可能出现数据不一致（网络分化），以及多了个步骤导致延迟会高一些。
2PC和3PC中故障情况分析相关推荐
- n个小球放入m个盒子中_N个球放入M个盒子中的情况分析
对于情况分析,主要参考: 本文只是对参考链接的简单"复制",最多会有比较详细的解释,不会有什么新的东西该类问题涉及到三个因素,分别是球是否有区别.盒子是否有区别.盒子是否可以为空. ...
- JQuery阻止冒泡事件on绑定中异常情况分析
本文转载自https://www.cnblogs.com/tengj/p/4794947.html,纯粹作为日常笔记使用 科普下事件冒泡以及默认行为,以下面例子举列子: 事件冒泡:当点击内部butto ...
- 分布式事务详解、理论分析、及强一致性(2PC、3PC)剖析
一. 简介 1. 什么是本地事务? 基于关系型数据库的事务,叫做本地事务,也叫做数据库事务. 本地事务通常是应用和数据库在一个服务器上,利用数据库本身的事务特性,从而实现本地事务. 数据库事务的特性: ...
- 浅谈大数据中的 2PC、3PC、Paxos、Raft、ZAB
一致性 简述 一致性,是指对每个节点一个数据的更新,整个集群都知道更新,并且是一致的.假设一个具有N个节点的分布式系统,当其满足以下条件时,我们说这个系统满足一致性: 全认同: 所有N个节点都认同一个 ...
- 金武士ups电源故障情况类型分析及维修
金武士ups电源故障情况类型分析及维修 一.金武士UPS电源无法启动 因为金勇士ups的电源是DC启动的,所以在电池没有连接.电池电量低或者电池有问题的情况下,UPS是无法启动的.下面有几种类似的情况 ...
- js自动触发onclick_每日一题JS中最基本的this情况分析
关注"前端学苑" ,坚持每天进步一点点 「~this情况分析 ~」 每日一题,希望让爱学习.思考的前端技术伙伴在一起学习.复盘.成长. 基础知识要夯实,原理源码要深入,深度广度要扩 ...
- 超详细解析 | 一致性协议算法-2PC、3PC、Paxos、Raft、ZAB、NWR
点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料! 来源:r6d.cn/VMW9 背景 在常见的分布式系统中, ...
- 一致性协议算法-2PC、3PC、Paxos、Raft、ZAB、NWR超详细解析
背景 在常见的分布式系统中,总会发生诸如机器宕机或网络异常(包括消息的延迟.丢失.重复.乱序,还有网络分区)等情况. 一致性算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中,快速且正确地 ...
- 分布式系统的一致性协议之 2PC 和 3PC
在分布式系统领域,有一个理论,对于分布式系统的设计影响非常大,那就是 CAP 理论,即对于一个分布式系统而言,它是无法同时满足 Consistency(强一致性).Availability(可用性) ...
最新文章
- RTSP协议-中文定义
- 24、JSON与OC互相转化
- 【Boost】Boost使用几条简单笔记
- echarts tooltip被遮挡_echarts 的tooltip定位到当前图，避免溢出和遮挡
- 华科00年计算机考研复试机试
- java mysql 动态sql_Java下拼接运行动态SQL语句
- python输出引号内的变量值_引号中的Python变量值
- [LeetCode]168. Excel Sheet Column Title
- 利用python操作mrjob实例---wordcount
- 使用FileUpload控件上传文件时对文件大小的限制
- 简历 java技能_java软件工程师简历专业技能填写样本
- 怎样在计算机上注册dll文件,注册dll文件【搞定步骤】
- 开源一款资源分享与下载工具 —— 电驴（eMule）
- 视频剪辑必备，5个音效素材网
- 从Sbo 2005B维护助手软件说说SBO人的四重境界
- linux的字体文件夹在哪里,把windows下的字体安装到Linux系统下的方法介绍
- 电脑桌面的word文件丢失了怎么找回？7个解决方法!
- java导出excel文件（标题为中文乱码）
- 在计算机软件中 BIOS的中文意思是,电脑bios是什么意思
- GB2312编码表(全)-Java程序打印