分布式协议与算法实战
韩健
腾讯资深工程师
23193 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 31 讲
分布式协议与算法实战
15
15
1.0x
00:00/00:00
登录|注册

03 | ACID理论:CAP的酸,追求一致性

事务型分布式系统的缺点
事务型分布式系统的优点
三阶段提交协议
幂等性
二阶段提交协议的思想
撤销阶段
确认阶段
预留阶段
问题与解决方案
提交执行阶段
提交请求阶段
分布式系统的ACID实现难点
单机实现ACID
课堂思考
内容小结
TCC(Try-Confirm-Cancel)
二阶段提交协议
ACID理论
ACID理论与分布式事务

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

你好,我是韩健。
提到 ACID,我想你并不陌生,很多同学也会觉得它容易理解,在单机上实现 ACID 也不难,比如可以通过锁、时间序列等机制保障操作的顺序执行,让系统实现 ACID 特性。但是,一说要实现分布式系统的 ACID 特性,很多同学就犯难了。那么问题来了,为什么分布式系统的 ACID 特性在实现上,比较难掌握呢?
在我看来,ACID 理论是对事务特性的抽象和总结,方便我们实现事务。你可以理解成:如果实现了操作的 ACID 特性,那么就实现了事务。而大多数人觉得比较难,是因为分布式系统涉及多个节点间的操作。加锁、时间序列等机制,只能保证单个节点上操作的 ACID 特性,无法保证节点间操作的 ACID 特性。
那么怎么做才会让实现不那么难呢?答案是你要掌握分布式事务协议,比如二阶段提交协议和 TCC(Try-Confirm-Cancel)。这也是我接下来重点和你分享的内容。
不过在带你了解二阶段提交协议和 TCC 之前,咱们先继续看看苏秦的故事,看这回苏秦又遇到了什么事儿。
最近呢,秦国按捺不住自己躁动的心,开始骚扰魏国边境,魏王头疼,向苏秦求助,苏秦认为“三晋一家亲”,建议魏王联合赵、韩一起对抗秦国。但是这三个国家实力都很弱,需要大家都同意联合,一致行动,如果有任何一方不方便行动,就取消整个计划。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式系统中实现ACID特性一直是一个挑战,本文介绍了二阶段提交协议和TCC协议作为解决方案。二阶段提交协议通过两个阶段的协商来确保事务要么全部执行,要么全部不执行,但存在资源预留和数据库独立性问题。相比之下,TCC协议是一个业务层面的协议,不依赖于数据库事务,能减轻数据库压力,但实现复杂度更高。总的来说,本文通过讲解这两种协议,帮助读者理解了分布式系统中实现ACID特性的难点以及解决方案。同时,文章还提到了幂等性和CAP理论对一致性的影响,为读者提供了更多思考和讨论的空间。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式协议与算法实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(54)

  • 最新
  • 精选
  • Joe Black
    在两阶段提交协议中,如果一个节点在第一阶段确认可以提交,然后崩溃了怎么办?第二阶段它实际没法真正应用自己那部分事务。这个看起来没法处理啊

    作者回复: 需要将提交相关信息保存到持久存储上,新进程启动后,恢复到之前的状态。

    2020-02-17
    19
    36
  • Undefined
    真正理解2PC和TCC的使用场景之后就不会分不清这两个东西,老师可以增加使用真实场景,希望老师在后面的讲解中加上相关分布式协议思想的真实场景,要不仅凭叙述理解起来确实麻烦 2PC用在集群间一致性数据同步,所有参与者完成的是同一件事,可以理解为它们在一个start transaction--commit里面,具有强一致性 TCC是对业务过程的拆分,一致性弱于2PC

    作者回复: 在TCC中,数据是最终一致。分布式事务和各算法场景,会在加餐篇做补充。

    2020-02-20
    29
  • 文中说到 两阶段提交的弊端:在提交请求阶段,需要预留资源,在资源预留期间,其他人不能操作 利用 TCC 可以解决,这里不是很明白,在 TCC中不是也有预留请求,同样预留资源的,难道在这期间其他事务可以使用这部分资源呢? 如果能使用预留资源,那么在执行Confirm确定操作的时候,之前预留的资源发生了变化,这样会不会有问题?

    作者回复: TCC是在业务服务中实现的,更灵活。

    2020-02-17
    10
    19
  • 沉淀的梦想
    老师在"二阶段提交存在的问题"中说 "数据库是独立的系统",是表达的什么意思?

    作者回复: 相比业务,数据库是独立的,也就是说,数据库是独立的第三方软件,咱们可以编程或修改业务代码,但,很少会修改数据库核心代码,更不会根据业务需求,修改实现不同的数据库代码逻辑。

    2020-02-17
    5
    15
  • 张克菲
    老师,在一次面试中被问到一个问题,如果一个transaction的rollback失败了,应该怎么办?回来后这个问题一直没有找到合适的答案,想看您能否分享一下您的思路?

    作者回复: 我的理解,可以考虑这几种方式或根据场景特点结合起来使用,1. 直接重试;2. 触发告警,然后人工根据日志记录进行修复;3. 设计异步回滚流程,也就是说在一个异步流程中对账、回滚,避免因重试耗时而拖慢整体性能。

    2020-04-07
    2
    13
  • 云学
    分享下我的理解,望指正:二阶段提交是保证不同系统/模块的逻辑结果一致,要么都成功,要么都失败,这些系统的物理数据是完全不相关的; 而Raft是保证多个系统的数据物理一致,举例1: 对于3副本存储系统,上传数据时肯定要保证这3个副本的数据物理一致, 举例2:对于一笔交易,需要通过2PC保证订单系统和库存系统的逻辑结果一致,但订单系统和库存系统的物理数据是完全不同的; 如果把2PC协商过程应用在同一个程序的不同进程,那就可以实现Raft效果了

    作者回复: 二阶段提交协议,是个原子提交协议,能实现事务,保证所有操作,要么全部执行,要么全部不执行。Raft是个共识算法,保证达成了共识的值,就不会再变了,基于Raft算法,能实现强一致性,也就是线性一致性。用途不同,可以简单这么理解,比如处理一个订单,需要执行A、B、C三个操作,二阶段提交协议,能保证3个操作要么全部执行,要么全部不执行。Raft能做到,你执行了A操作后,你就一致能读到A操作执行后的结果。

    2020-02-22
    2
    12
  • 时彬斌
    关于一致性有些疑问,强一致性、最终一致性的区别不是很清晰,之前学习raft的时候看到,raft的leader在收到集群内一半以上的数据节点确认操作后就认为事务完成,这时有些节点的数据并没有更新完成,此时理解应该为最终一致性,为什么说raft是强一致性呢?raft强一致性难道仅仅体现在所有请求的处理都是在leader节点处理吗?

    作者回复: 强一致性,是指基于Raft能实现线性一致性,线性一致性通常被称为强一致性。你提到的这个情况是存在的,“大多数”原则导致的。可以这么理解,Raft是共识算法,Raft自身的数据是最终一致的(大多数原则决定的),但是基于Raft(加上客户端协议),我们能实现强一致性系统,比如强一致性KV存储系统。而我们通常说,Raft是强一致性,其实指的是,我们基于Raft这个算法实现的系统是强一致性的。

    2020-02-21
    5
    10
  • 一直有个问题,两阶段协议解决的是分布式事务问题,而raft 这些解决的是分布式数据共识问题,即数据在主从副本的条件下保持数据对外始终一样。为什么这两个总混在一起说是解决一致性的呢???

    作者回复: 常被误解的一个概念,在中文语义中,Consensus和Consistency都被翻译为了一致性。后面,会做个加餐篇,具体说说:)。

    2020-02-17
    8
    9
  • 感觉 TCC 也采用了两阶段提交的思想,是不是 TCC 是两阶段提交思想的一种实现? 在看文中的图,是代表 TCC 中,是客户端直接通知所有的节点吗?没有所谓的协作者了?

    作者回复: 加一颗星:),客户端在扮演协调者的角色。

    2020-02-17
    8
  • 张高
    文中只说明了预留阶段出错了如何撤销,却没有说明:如果确认阶段出错了,该怎么处理。

    作者回复: 通过预留阶段的确认,保证确认阶段执行不会出错。

    2020-02-17
    4
    6
收起评论
显示
设置
留言
54
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部