深入浅出分布式技术原理
陈现麟
伴鱼技术中台负责人,前小米工程师
21241 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
深入浅出分布式技术原理
15
15
1.0x
00:00/00:00
登录|注册

23|事务(二):原子性,对应用层提供的完美抽象

阶段 2 的承诺:协调者的决定不可撤销
阶段 1 的承诺:参与节点能够安全提交
提交点:协调者将决定写入事务日志
两个关键承诺
阶段 2:提交或中止
阶段 1:准备阶段
关键点
两阶段提交(2PC)
Redo Log 保证持久性,Undo Log 保证原子性
顺序:先写入 Undo Log 和 Redo Log,然后写入 Commit 记录
使用 Undo Log、Redo Log 和 Commit 记录
与隔离性分开定义
all-or-nothing
可串行化的隔离性(线程安全)
整体的不可分割性
3PC 协议的具体实现和防止阻塞的机制
2PC 是分布式事务中使用最多的原子提交协议
单节点事务和分布式事务的原子性实现方式
事务的原子性与操作系统的原子操作不同
存在高延迟和网络分区下不一致的问题
解决了 2PC 的阻塞问题
在 2PC 的基础上增加阶段和超时机制
不能保证多个节点的事务操作同时提交
逆可用性协议
阻塞式协议
分布式事务
单节点事务
事务中的原子性
操作系统中的原子操作
思考题
总结
3PC 协议
2PC 面临的问题
实现原子性
定义
事务的原子性

该思维导图由 AI 生成,仅供参考

你好,我是陈现麟。
通过上节课的学习,我们理解了事务的一致性的定义,并且知道了事务一致性的实现,是通过底层存储的多副本数据强一致性,事务的原子性、隔离性和持久性一起协作,以及数据库层和应用层的约束检测等各方面来保障的,那么本节课,我们就继续来讨论事务中,另一个非常重要的特性:原子性。我们从原子性的定义出发,一起分析在分布式系统中,原子性的实现方法,最后再对原子性的关键问题进行讨论。
当我们对事务的原子性进行讨论和学习后,你就能明白原子性是一个非常完美的抽象,因为它对应用程序,屏蔽了分布式系统中部分失败的问题,这可以大大减少我们在编程时的心智负担。

原子性的定义

一般来说,我们在计算机领域第一次接触“原子”这一概念,都来源于操作系统的“原子操作”。在操作系统中,原子操作的定义是指,不可被中断的一个或者一系列操作,它包含了两个层面的意思。
首先,是整体的不可分割性。一个原子操作的所有操作,要么全部执行,要么就一个都不执行,即 all-or-nothing 。
其次,是可串行化的隔离性,即线程安全。原子操作是在单核 CPU 时代定义的,由于原子操作是不可中断的,那么系统在执行原子操作的过程中,唯一的 CPU 就被占用了,这就确保了原子操作的临界区,不会出现竞争的情况。原子操作自带了线程安全的保证,即最严格的隔离级别的可串行化,所以我们在编程的时候,就不需要对原子操作加锁,来保护它的临界区了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式系统中的事务原子性是一个重要的特性,它提供了完美的抽象,屏蔽了分布式系统中的部分失败问题,减少了编程时的心智负担。在单节点事务中,通过Undo Log、Redo Log和Commit记录来实现原子性,保证了事务的持久性和原子提交。而在分布式事务中,通过两阶段提交(2PC)来解决部分节点失败导致的操作分割,实现了事务的原子性。然而,2PC协议存在阻塞问题和逆可用性问题,因此后来提出了3PC协议,但其效果并不理想。尽管2PC在性能、可用性和可见性方面存在问题,但它仍然是当前分布式事务场景中使用最广泛的原子提交协议。总之,原子性的实现方法涉及单节点事务和分布式事务两个维度,通过不同的机制来保证事务的原子性,从而提供了完美的抽象,减少了对开发者的负担。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入浅出分布式技术原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(4)

  • 最新
  • 精选
  • peter
    请教老师一个问题: Q1:seata是2PC还是3PC? springcloud体系架构中,seata是一个流行框架,那么,seat属于2PC 还是3PC?

    作者回复: 是 2PC,不过为了性能,在锁等资源的持有上有一些优化。

    2022-03-25
    4
  • nothing
    1. 3PC对于协调者和参与者都设置了超时时间,而2PC只有协调者才拥有超时机制。这个优化点,主要是避免了参与者在长时间无法与协调者节点通讯(协调者挂掉了)的情况下,无法释放资源的问题,因为参与者自身拥有超时机制会在超时后,自动进行本commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。 2. 通过CanCommit、PreCommit、DoCommit三个阶段的设计,多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。 但是3PC依然没有完全解决数据不一致的问题。
    2022-04-06
    1
  • Geek_27a248
    老师,您好,有个不是很明确的问题,就是2pc再阶段2,发起提交的时候,3个节点,2个成功,一个失败。 1、协调者是认为事务是成功的吗 2、此时失败的节点是否会同步2个成功节点的数据恢复到正常状态 3、发起回滚请求时也是如此吗 4、协调者在收到2个成功节点的ack之后,剩余一个失败的ack是怎么处理的呢 谢谢老师
    2023-04-25归属地:北京
  • Next
    “如果协调者在事务执行过程中崩溃了,那么等到协调者恢复后,在事务日志中如果没有发现未解决的事务,就中止事务;反之,就会继续执行事务。” 这里不理解, 请老师解答
    2022-05-08
收起评论
显示
设置
留言
4
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部