分布式金融架构课
任杰
eBay 支付账务系统负责人,前蚂蚁金服架构师
19876 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
开篇词 (1讲)
分布式金融架构课
15
15
1.0x
00:00/00:00
登录|注册

13 | 正确性分级(中):多机无容灾有哪几种不同的一致性实现?

你好,我是任杰。这一讲我想和你聊一聊怎么在多机无容灾的情况下保证一致性。
我在前一节课里给你介绍了,在单机情况下的 5 种不同的一致性级别。在分布式环境下,由于网络存在很大的不确定性,金融系统首要关心的不是如何在这些一致性中做选择,而是理论上有没有可能达到最高的正确性。那么这节课我们就来学习一下最常用的两个方法。

背景

在分布式环境下,每个节点上的数据库都会保证这台机器的数据操作具有可串行化或者快照隔离的事务隔离级别,但是这只是本地机器局部的事务保证,是分散的信息。
如果想要具有分布式事务(Distributed Transaction)的能力,就需要有个方法把局部的信息收集起来做集中决策。这个收集的过程和做集中决策的过程也需要有事务的保证。通过单机事务来达到多机之间的事务协调,通过单机事务的正确性来保证全局事务的正确性,你在后面的学习中一定要注意这个核心思路。
分布式事务的实现也分为两种不同的级别。一种是偏底层的实现,由数据库自己来实现分布式事务,比较著名的有两阶段提交(2PC)和三阶段提交(3PC)。另一种是偏上层实现,业务系统自己来实现分布式事务,在国内比较常见的是 TCC。接下来我们先看看两阶段提交。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式系统中保证一致性是一个重要的挑战,本文介绍了两种不同的方法:两阶段提交(2PC)和TCC协议。两阶段提交分为准备提交和提交或回滚两个阶段,而TCC协议则分为尝试和确认或取消两个阶段。两者的区别在于TCC需要业务系统负责整个分布式事务的执行,而两阶段提交需要数据库修改自己的逻辑。文章通过具体的例子和图示生动地解释了两种方法的实现过程和成本,帮助读者快速了解分布式事务的一致性保证方法。在TCC的情况下,业务系统控制了分布式事务的进程,暴露了一些临时的不一致状态,但最终保证了正确性。总的来说,本文深入浅出地介绍了分布式一致性保证的两种方法,为读者提供了宝贵的技术知识。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式金融架构课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • qinsi
    疑问: 文中TCC的例子是 A:尝试提交阶段:-100 确认阶段:什么都不做 取消阶段:+100 B:尝试提交阶段:什么都不做 确认阶段:+100 取消阶段:什么都不做 似乎更容易想到的是这样实现: A:尝试提交阶段:-100 确认阶段:什么都不做 取消阶段:+100 B:尝试提交阶段:+100 确认阶段:什么都不做 取消阶段:-100 这样的话正常情况下第一阶段过后系统的状态也是一致的,A和B其中之一出错的话,取消阶段也只需取消另一个,相比之下没有额外的开销。选择第一种实现方式还有什么其它的考量吗?

    作者回复: qinsi同学你好。在你提到的第二种选择下,由于TCC不会长期持有数据库锁,因此B在第一阶段提交后会真正入账100元。这时候如果B突然通过别的业务转走这一笔钱,那么当TCC回滚的时候,会发现这100元不能补给A。 因此,第一种方式在错误处理上会更好一些。

    2021-01-22
    4
    8
  • tt
    事务的原子性就是不能有中间状态的存在,要么成功,要么失败。两阶段提交正好有一个中间状态——准备成功。 如果全局事务数据丢失,协调者是不是可以向所有资源管理者发送状态询问消息,如果资源管理者存在中间状态,则让他们都回滚或提交。 如果采取上面说的办法,那么就需要解决的如何匹配两个处于“准备成功”状态的账户是属于同一笔交易的问题了,即找到一个“破损交易的另一半”。 所以,应该在交易将要开始前,在每个资源管理者本地的数据库中记录全局交易的ID,这样就可以把N个处于中间状态的账户关联起来了。这样相当于把协调者的全局数据在资源管理者出“冗余”了一份。有了这个信息,协调者又可以愉快的玩耍了: 1、如果两个关联账户都处于“准备成功”状态,那么让它们都会滚。 2.1、如果一个处于已提交状态,一个处于“准备成功”状态,则进行补偿,让后者变为成功状态。 2.2、如果这和业务需求不符合,则两者都提交后,再发起一笔反向交易,将状态都修改为交易之前的状态。
    2021-01-22
    3
  • silentyears
    银行间跨行转账如何实现一致性的,毕竟A行不能直接操作B行数据,是调用B服务
    2022-11-15归属地:北京
  • Leo Lee
    疑问: TCC在cancel阶段也可能失败,那怎么办?感觉这里是个悖论,通知节点cancel,但cancel本身也可能失败,那就每完没了了,反复尝试,直至成功cancel吗?
    2022-04-08
  • IT生涯路漫漫
    用分布式数据库自身的快照日志和事务日志相结合能倒推出来吧
    2022-03-23
  • ezekiel
    在第一阶段,协调者向所有参与的数据库发送准备提交的消息。每个数据库在收到协调者的消息之后,对自己本地的数据库进行预处理,比如给数据加锁、修改数据等等。如果预处理成功,本地数据库返回准备成功的消息给协调者。如果预处理失败,则返回准备失败的消息。请注意,这时候本地的数据库事务还没有完成,也就是既没有提交事务,也没有回滚事务。 你有没有发现一个悖论?对于在第一阶段操作成功了的数据库来说,这些操作已经提交了,那已经提交了的事务怎么可能在第二阶段回滚呢?事务不是要求已经提交的事务不能回滚吗? 这两段话应该怎么理解呢?第一阶段产生的事务提交了?
    2021-10-28
  • luke
    事件溯源的分布式系统如何实现分布式事务?
    2021-05-07
  • “TCC 情况下的跨机器转账”这个案例中,其实阶段1也要求一个一致性,数据库A和全局事物管理器的一致性,TCC阶段1内部这里也可以采用2PC来实现。
    2021-03-08
  • “在单机版和两阶段提交的情况下,数据库隐藏了所有上面这些中间细节,因此你会感觉事务有原子性。但是在 TCC 的情况下,由于业务系统控制了分布式事务的进程,这些中间状态会暴露给业务系统,因此你才能感受到一些临时的不一致状态。”2PC、3PC、TCC的概念其实已经再熟悉不过了,但是感觉这句话感觉老师有自己的东西,果断买课。
    2021-03-08
  • webmin
    前面的课程老师有教过通过记录事件,在需要回溯时,通过回放一段时间事件的方法来得到某个指标的最后状态,我想协调者也可以通过这种方法来得到最后状态,协调者的数据库是记录事物的最后的状态,在协调事件的发生过程中涉及到事件可以通过WAL方式记录写入磁盘中,协调者DB不能用时,协调者可以通过向前追溯未完事件ID的方法来得到当前还未完成事物的各方所处阶段。 当然还可以通过共识算法来达成一至,但这就超出了2PC和TCC的范畴了。
    2021-01-23
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部