2pc和3pc的比较

2pc

二阶段提交的问题:

1,协调者存在单点故障;

2,协调者通知参与者执行提交或回滚时,无法保证所有参与者都能成功执行,即存在数据不一致的问题

3pc

1,预备阶段:询问参与者是或执行本地事务,返回同意或者终止;

2,准备阶段,发送执行本地事务请求,参与者记录日志,执行本地事务,返回执行成功或失败;

3,提交阶段,协调者发送提交或回滚请求,参与者执行,返回成功或者失败。

预备阶段返回同意,大概率说明参与者能顺利执行本地事务,如果参与者准备阶段都记录日志,事务执行成功,此时出现协调者异常或协调者和参与者之间网络故障,即协调者的提交号没有到达参与者,参与者在等待超时后,默认提交本地事务

总结:

在三阶段提交的准备阶段,协调者必须收到所有参与者的确认才能进入提交阶段。只要有一个参与者没响应(或超时),协调者就会选择中断回滚事务。

协调者发送提交请求,其中一个参与者执行失败,其他执行成功,那是不是也无法回滚了?
简短回答:是的,在这种情况下,理论上已经无法回滚了,系统会陷入"部分成功、部分失败"的不一致状态(也就是我们常说的"数据不一致"或"脑裂",通过补偿方案,调整数据,实现最终一致性)。

3PC 的设计初衷主要是为了解决 2PC 的阻塞问题 (即协调者挂了,参与者卡住不动),而不是为了解决提交时的执行失败问题。

相关推荐
姜鱼问生18 分钟前
docker exec 排查容器问题:从日志到进程
运维·网络·数据库·docker·容器
狗凯之家源码网1 小时前
AI 步数修改提交系统源码应用场景与落地指南
android·数据库·人工智能·运动步数
穆梓兰煊1 小时前
AI供应链安全不再只是包安全,还涉及模型与数据
前端·数据库
北风toto1 小时前
数据库笔记:Armstrong 公理系统与集合论的深度辨析
数据库·笔记
小蒜学长1 小时前
基于SpringBoot+Vue的租房管理系统的设计与实现(代码+数据库+LW)
java·数据库·spring boot·后端·租房管理
一只专注api接口开发的技术猿1 小时前
Open‑Claw 实战|告别页面逆向,快速搭建电商商品监控与数据分析完整方案
大数据·数据库·python·数据挖掘·数据分析
雨落在了我的手上1 小时前
MySQL数据库基础(6):增删改查操作(1)
数据库·mysql
Omics Pro1 小时前
全新可重分析!代谢组质谱专用
数据库·人工智能·算法·机器学习·自然语言处理
ITOM运维行者2 小时前
网络丢包监控怎么做?从六大成因到接口级定位的排查路径
数据库·人工智能·机器学习