分布式金融架构课
任杰
eBay 支付账务系统负责人,前蚂蚁金服架构师
2445 人已学习
立即订阅
登录后,你可以任选4讲全文学习
推荐试读
换一换
02 | 原理解读:如何理解第三方支付的业务逻辑和系统组件?
13 | 正确性分级(中):多机无容灾有哪几种不同的一致性实现?
15 | 分布式正确性的存在性(上):什么情况下不存在分布式共识算法?
课程目录
已完结/共 30 讲
开篇词 (1讲)
开篇词 | 如何成为金融级人才?
金融业务与系统 (6讲)
01 | 业务初探:扫了二维码之后发生了什么?
02 | 原理解读:如何理解第三方支付的业务逻辑和系统组件?
03 | 产品大观:不同金融业务都有哪些技术实现要点?
04 | 领域驱动设计(上):如何设计金融软件顶层架构?
05 | 领域驱动设计(下):如何设计统一的金融业务模型?
答疑集锦(一) | 思考题解析与外汇架构知识拓展
系统正确性保障 (7讲)
06 | 计算输入的正确性:怎么选择正确时间的数据?
07 | 计算过程的正确性:如何设计正确的数据处理架构?
08 | 计算结果的正确性:怎么保证计算结果是正确的?
09 | 数据传输的质量:金融业务对数据传输有什么要求?
10 | 数据存储的合理性:金融业务可以不用关系型数据库吗?
11 | 系统优化:如何让金融系统运行得更快?
答疑集锦(二) | 思考题解析与账务系统优化
分布式正确性及高可用 (11讲)
12 | 正确性分级(上):单机无备份有哪几种不同的一致性?
13 | 正确性分级(中):多机无容灾有哪几种不同的一致性实现?
14 | 正确性分级(下):多机有容灾有哪几种不同的一致性?
15 | 分布式正确性的存在性(上):什么情况下不存在分布式共识算法?
16 | 分布式一致性(下):怎么理解最简单的分布式一致性算法?
17 | 正确性案例(上):如何实现分布式的事件溯源架构?
18 | 正确性案例(中):常见分布式数据方案的设计原理是什么?
19 | 正确性案例(下):如何在运行时进行数据系统的动态分库?
20 | 容灾(上)如何实现正确的跨机房实时容灾?
21 | 容灾(下):如何通过混沌工程提高系统稳定性?
答疑集锦(三) | 思考题解析与数据库底层实现
春节策划 (3讲)
春节策划第1期 | 分布式金融系统知识,你掌握了多少?
春节策划第2期 | 读书如抽丝,为你推荐一些我读过的好书
春节策划第3期 | 如何运用架构知识解读春运买票和手游案例?
结束语 (2讲)
结束语 | 金融之道,与你同行,虽远尤欣
结课测试|这些金融架构的问题,你都掌握了么?
分布式金融架构课
15
15
1.0x
00:00/00:00
登录|注册
开通超级会员可免费学习本课程,还可解锁海量内容免费学特权。

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

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

背景

在分布式环境下,每个节点上的数据库都会保证这台机器的数据操作具有可串行化或者快照隔离的事务隔离级别,但是这只是本地机器局部的事务保证,是分散的信息。
如果想要具有分布式事务(Distributed Transaction)的能力,就需要有个方法把局部的信息收集起来做集中决策。这个收集的过程和做集中决策的过程也需要有事务的保证。通过单机事务来达到多机之间的事务协调,通过单机事务的正确性来保证全局事务的正确性,你在后面的学习中一定要注意这个核心思路。
分布式事务的实现也分为两种不同的级别。一种是偏底层的实现,由数据库自己来实现分布式事务,比较著名的有两阶段提交(2PC)和三阶段提交(3PC)。另一种是偏上层实现,业务系统自己来实现分布式事务,在国内比较常见的是 TCC。接下来我们先看看两阶段提交。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
02 | 原理解读:如何理解第三方支付的业务逻辑和系统组件?
13 | 正确性分级(中):多机无容灾有哪几种不同的一致性实现?
15 | 分布式正确性的存在性(上):什么情况下不存在分布式共识算法?
17 | 正确性案例(上):如何实现分布式的事件溯源架构?
18 | 正确性案例(中):常见分布式数据方案的设计原理是什么?
21 | 容灾(下):如何通过混沌工程提高系统稳定性?
开通超级会员免费畅看本课程
开通会员
该文章仅可免费阅读部分内容,如需阅读完整文章,请开通超级会员或单独购买本课程。
登录 后留言

精选留言(7)

  • 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
    6
  • tt
    事务的原子性就是不能有中间状态的存在,要么成功,要么失败。两阶段提交正好有一个中间状态——准备成功。

    如果全局事务数据丢失,协调者是不是可以向所有资源管理者发送状态询问消息,如果资源管理者存在中间状态,则让他们都回滚或提交。

    如果采取上面说的办法,那么就需要解决的如何匹配两个处于“准备成功”状态的账户是属于同一笔交易的问题了,即找到一个“破损交易的另一半”。

    所以,应该在交易将要开始前,在每个资源管理者本地的数据库中记录全局交易的ID,这样就可以把N个处于中间状态的账户关联起来了。这样相当于把协调者的全局数据在资源管理者出“冗余”了一份。有了这个信息,协调者又可以愉快的玩耍了:

    1、如果两个关联账户都处于“准备成功”状态,那么让它们都会滚。

    2.1、如果一个处于已提交状态,一个处于“准备成功”状态,则进行补偿,让后者变为成功状态。

    2.2、如果这和业务需求不符合,则两者都提交后,再发起一笔反向交易,将状态都修改为交易之前的状态。
    2021-01-22
    3
  • 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
收起评论
7
返回
顶部