分布式技术原理与算法解析
聂鹏程
智载云帆CTO,前华为分布式Lab资深技术专家
立即订阅
5969 人已学习
课程目录
已更新 36 讲 / 共 34 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 四纵四横,带你透彻理解分布式技术
免费
01 | 分布式缘何而起:从单兵,到游击队,到集团军
02 | 分布式系统的指标:啥是分布式的三围
第一站:分布式协调与同步 (6讲)
03 | 分布式互斥:有你没我,有我没你
04 | 分布式选举:国不可一日无君
05 | 分布式共识:存异求同
06 | 分布式事务:All or nothing
07 | 分布式锁:关键重地,非请勿入
08 | 分布式技术是如何引爆人工智能的?
第二站:分布式资源管理与负载调度 (6讲)
09 | 分布式体系结构之集中式结构:一人在上,万人在下
10 | 分布式体系结构之非集中式结构:众生平等
11 | 分布式调度架构之单体调度:物质文明、精神文明一手抓
12 | 分布式调度架构之两层调度:物质文明、精神文明两手抓
13 | 分布式调度架构之共享状态调度:物质文明、精神文明多手协商抓
14 | 答疑篇:分布式事务与分布式锁相关问题
第三站:分布式计算技术 (4讲)
15 | 分布式计算模式之MR:一门同流合污的艺术
16 | 分布式计算模式之Stream:一门背锅的艺术
17 | 分布式计算模式之Actor:一门甩锅的艺术
18 | 分布式计算模式之流水线:你方唱罢我登场
第四站:分布式通信技术 (4讲)
19 | 分布式通信之远程调用:我是你的千里眼
20 | 分布式通信之发布订阅:送货上门
21 | 分布式通信之消息队列:货物自取
22 | 答疑篇:分布式体系架构与分布式计算相关问题
第五站:分布式数据存储 (5讲)
23 | CAP理论:这顶帽子我不想要
24 | 分布式数据存储系统之三要素:顾客、导购与货架
25 | 数据分布方式之哈希与一致性哈希:“掐指一算”与“掐指两算”的事
26 | 分布式数据复制技术:分身有术
27 | 分布式数据之缓存技术:“身手钥钱”随身带
特别放送 (3讲)
特别放送 | 分布式下的一致性杂谈
特别放送 | 徐志强:学习这件事儿,不到长城非好汉
特别放送 | 那些你不能错过的分布式系统论文
第六站:分布式高可靠 (5讲)
28 | 分布式高可靠之负载均衡:不患寡,而患不均
29 | 分布式高可靠之流量控制:大禹治水,在疏不在堵
30 | 分布式高可用之故障隔离:当断不断,反受其乱
31 | 分布式高可用之故障恢复:知错能改,善莫大焉
32 | 答疑篇:如何判断并解决网络分区问题?
分布式技术原理与算法解析
登录|注册

06 | 分布式事务:All or nothing

聂鹏程 2019-10-04
你好,我是聂鹏程。今天,我来继续带你打卡分布式核心技术。
对于网上购物的每一笔订单来说,电商平台一般都会有两个核心步骤:一是订单业务采取下订单操作,二是库存业务采取减库存操作。
通常,这两个业务会运行在不同的机器上,甚至是运行在不同区域的机器上。针对同一笔订单,当且仅当订单操作和减库存操作一致时,才能保证交易的正确性。也就是说一笔订单,只有这两个操作都完成,才能算做处理成功,否则处理失败,充分体现了“All or nothing”的思想。
在分布式领域中,这个问题就是分布式事务问题。那么今天,我们就一起打卡分布式事务吧。

什么是分布式事务?

要想理解分布式事务,我们首先来看一下什么是事务。
事务,其实是包含一系列操作的、一个有边界的工作序列,有明确的开始和结束标志,且要么被完全执行,要么完全失败,即 all or nothing。通常情况下,我们所说的事务指的都是本地事务,也就是在单机上的事务。
分布式事务,就是在分布式系统中运行的事务,由多个本地事务组合而成。在分布式场景下,对事务的处理操作可能来自不同的机器,甚至是来自不同的操作系统。文章开头提到的电商处理订单问题,就是典型的分布式事务。
要深入理解分布式事务,我们首先需要了解它的特征。分布式事务是多个事务的组合,那么事务的特征 ACID,也是分布式事务的基本特征,其中 ACID 具体含义如下:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式技术原理与算法解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(36)

  • 约书亚

    疑问不少
    1. 2pc和3pc的第一步到底是不是“类似”?从本文中看,2pc corhort 收到CanCommit已经开始执行事务但不提交,3pc则写着在PreCommit阶段开始预提交。文中说二者第一步“类似”,但其实是非常不类似的吧?
    2. 我看到的资料里,3pc出现的目的,并不是文中说的为了解决那两个问题,因为这两个问题的解决方案在2pc中也可以引入。同步阻塞问题和本地事务隔离性相关。数据不一致在两者也都会出现。3pc多了一步,这些就能避免了么?
    3pc很多机制在这里没提到,这些才是真正对比2pc的改进。比如只要coordinator收到大多数ack,第三阶段即进入commit状态。本质上3pc并不能像共识算法那样保证一致性,而是比起2pc,增加了在一些未知状态下,“状态可能是成功”的判断依据。
    3. 分布式消息中间件实现事务,重点是回查,这点没提啊。

    作者回复: 从你的提问中,可以看出你很爱思考。首先,非常抱歉,因为要忙每周的上线稿子定稿和后续新章节,所以没能及时回复,后面我会注意这个问题,尽量及时回复,希望理解。下面看一下这三个问题:
    1. 2pc和3pc的第一步在文中的类似是指,均是通过协调者询问参与者是否可以正常执行事务提交操作,参与者也都会给协调者回复。在2pc中,如果所有参与者都返回结果后,会进入第二阶段的提交阶段,也可以说是执行阶段,根据第一阶段的投票结果,进行提交或取消。在3pc中,进入真正的提交阶段前,会有一个预提交阶段,这个预提交阶段不会做真正的提交,会将相关信息记录到事物日志中,当所有参与者都返回YES后,才会进入真正的提交阶段或执行阶段。
    2. 3pc通过在协调者和参与者均引入了超时机制(2pc只是在协调者引入了超时)减少了整个集群的阻塞时间,在一定程度上减少或减弱了2pc中出现的同步阻塞问题;3pc中引入了预提交阶段,相对于2pc来讲,相当于增加了一个缓冲,保证了在最后提交阶段之前各参与节点的状态是一致的。
    3. 不知道你说的回查是不是指的“失败重试”?如果是的话,这个和业务设计有关系,在介绍ebay系统中有提到,但本文主要是针对基于分布式消息的最终一致性方案的原理进行介绍,所以没有展开介绍。

    2019-10-04
    6
    27
  • 逆流的鱼
    三阶段为什么就不阻塞了?没明白

    作者回复: 不阻塞的主要原因是在三阶段中引入了超时机制,有了超时机制协调者不用死等其它节点,其它节点也无需死等协调者,从而不会造成堵塞。

    2019-10-10
    4
  • 樂文💤

    不太明白基于消息队列的方法如何解决数据不一致的问题 如果现在我有四个功能模块 前三个都成功了 按照文中所示协调者已经将前三个模块数据作出修改 但此时如果第四个模块数据更新失败的话 前三个模块如何做到回滚 因为前三个模块都没有锁定数据库资源
    2019-10-16
    2
    3
  • 忆水寒
    分布式互斥是访问某一个共享资源防止产生不一致现象。分布式事务,是保证一组命令的完整执行或完全不执行。过程来看,都是保证数据一致性的手段。但是两者又不一样,互斥不可以回退(除非发起反向新操作),事务可以回退。
    2019-10-04
    3
  • A:春哥大魔王
    可靠消息这种方式必须采用mq吗?使用db是不是也可以,看起来只是一个事务状态的存储和管理,是多个两阶段提交的组合啊!

    作者回复: 你这个问题提的很好!没有说必须采用MQ,但是MQ天生就是为了高效信息交互而生,所以我在这里是以MQ进行讲解的。使用DB自然是可以的,不过考虑到DB为了保证各种约束而产生的开销,性能上肯定会打一定的折扣。

    2019-10-06
    2
  • 随心而至
    老师能不能放一些参考链接放出来,或者一些引申的链接
    2019-10-05
    2
  • 公共号
    分布式消息中间件咋解决分布式事务回滚呢,觉得只是搞了个中间件把同步调用改成异步了,记录了状态。
    2019-10-12
    1
  • Luciano李鑫
    总结了很久,总结出来我的问题是,文中提到的两阶段提交或者三阶段提交应该算是协议层的抽象,想知道具体实现这些协议的项目中协调者和参与者分别是哪些,和他们的关系。
    2019-10-12
    1
  • ChenLicong
    三阶段也有一个协调者,为什么就不会有单点故障了?

    作者回复: 不是绝对地没有单点故障问题了,是一定程度上减少了单点故障带来的问题。三阶段协议中,参与者也引入了超时机制,如果长时间没有得到协调者的响应,在默认情况下,参与者会自动将超时的事务进行提交,不会像两阶段提交那样被阻塞住。

    2019-10-09
    1
  • Geek_54edc1
    个人感觉应该是分布式事务在并发时会用到分布式互斥,比如基于XA协议,在多个分布式事务并发时,哪个会占用事务管理器资源,这时就会用到分布式互斥;基于分布式消息,消息中间件是不用互斥占用的,但是与消息中间件交互的其他资源管理模块(比如订单模块,支付模块等)在多个事务并发的情况下,就需要有互斥机制了
    2019-10-04
    1
  • 安排
    上节说到分布式共识算法是保障系统满足不同程度一致性的核心算法,那这里的2pc,3pc可以认为是一种分布式共识算法吗?
    还有paxos,2pc,3pc等等,这些一致性算法都用在哪些场景呢?最主要的是paxos的应用场景有哪些?
    2019-12-11
  • 倾听
    2pc和3pc都会存在数据不一致问题,为什么属于强一致性方案?
    2019-11-22
  • 愚人
    基于消息的分布式事务,所给的例子中,如果支付失败或者出货,如何触发“订单系统”回滚?此外,这里的订单,支付和仓库三个节点更像是流水线,而不是事务的概念
    2019-11-16
  • 💢 星星💢
    我觉得互斥是保证事务一致性的前提,如果二个参与者都不互斥,怎么保证数据的一致性呢,肯定要有个排队等待的阶段。不然会出现数据混乱。。另外想听听老师的对这个问题的看法。
    2019-11-16
  • ~风铃~
    两阶段提交或者三阶段提交的应用场景一般只在数据库之间吧,而且数据库要能支持相关的协议。 比如记录回滚日志,如果不是数据库本身🈶️实现,其他资源要实现很复杂
    2019-11-11
  • Geek_xiaoer
    1. "在 DoCommit 阶段,当参与者向协调者发送 Ack 消息后,如果长时间没有得到协调者的响应,在默认情况下,参与者会自动将超时的事务进行提交,不会像两阶段提交那样被阻塞住。"
    在"DoCommit"阶段,当参与者向协调者发送 Ack 消息后,协调者需要响应吗?
    2. "为了解决两阶段提交的同步阻塞和数据不一致问题,三阶段提交引入了超时机制和准备阶段"
    "2PC 和 3PC 这两种方法,有两个共同的缺点,***二是,没有解决数据不一致的问题。"
    所以3PC有没有解决数据一致性问题?
    3. 说实话,感觉很多东西都没讲清楚,有点失望
    4. 期待讲的细致一点,把问题讲清楚,而不是把概念仍一下就完了

    2019-11-07
  • 白杨付
    如果2pc 参与者也引入超时机制呢?那么这种情况下,3pc的优势是什么?
    2019-10-29
  • Eternal
    我有一个疑问:3pc的第二个阶段,预提交的时候,将undo,redo日志记录,这个是怎么做到的,本地事务只能提交和回滚两个操作,只提交一半这个操作是业务系统自己通过数据库存undo,redo操作来模拟的吗?也就是最终提交的时候才是真的提交数据库本地事务。
    2019-10-24
  • 王博
    三阶段提交一定能保证数据一致吗,假设三台机器A,B,C.PreCommit时A挂了,此时BC应该用undo log回滚,假设B在收到协调者回滚消息之前挂了会怎么样
    2019-10-22
  • overland
    如果开发这个2pc或者3pc,是单独部署吗,和业务系统怎么对接呢,rpc接口吗,也要保障他的高可用吧?
    2019-10-22
收起评论
36
返回
顶部