分布式金融架构课
任杰
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
登录|注册
开通超级会员可免费学习本课程,还可解锁海量内容免费学特权。

17 | 正确性案例(上):如何实现分布式的事件溯源架构?

你好,我是任杰。这一讲我想和你聊一聊怎么实现分布式的事件溯源架构。
第 7 节课,我们讲了单机版的事件溯源架构。尽管这个架构处理能力快,但是单台机器的处理能力毕竟有限,而且也不能保证系统有容灾能力。
所以,这节课我们一起来看看,如何一步一步解决系统扩容和容灾的问题。这里我先做个提示,因为这节课会用到很多前面讲过的内容,必要的地方我会给你说明关联到前面哪一节课。我建议你先把握整体思路,有弄不懂的,可以再温习一下前面的内容。
这节课要讲的解决问题的思路,不仅仅适用于事件溯源架构,很多和计算及数据相关的系统也会碰到同样的挑战。所以,你在学习这节课时,重点要放在理解为什么会有这些问题,以及为什么有这些解决方案,而不是放在解决方案的细节上。

多机容灾

我们先来看看分布式环境下我们能解决的第一个问题,那就是容灾。
容灾的思路是花钱来换取服务质量。如果单台机器出问题之后无法对外提供服务,那么只要我们能把同一个功能部署在多台机器上就行,这些机器作为一个整体对外提供服务。如果一台机器坏掉了的话,只要集群里还有其他的机器,那么就能再找一台机器,替换掉前面那台坏掉的。
刚才的分析看似正确,但隐含着三个重要的假设。这几个假设会直接影响到我们的架构能达到的正确性级别。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
02 | 原理解读:如何理解第三方支付的业务逻辑和系统组件?
13 | 正确性分级(中):多机无容灾有哪几种不同的一致性实现?
15 | 分布式正确性的存在性(上):什么情况下不存在分布式共识算法?
17 | 正确性案例(上):如何实现分布式的事件溯源架构?
21 | 容灾(下):如何通过混沌工程提高系统稳定性?
春节策划第2期 | 读书如抽丝,为你推荐一些我读过的好书
开通超级会员免费畅看本课程
开通会员
该文章仅可免费阅读部分内容,如需阅读完整文章,请开通超级会员或单独购买本课程。
登录 后留言

精选留言(4)

  • webmin
    使用推或拉,需要根据同步事件量、及时性和需要同步事件的消费者数量三个方面来评估,
    1. 对于及时性要求非常高的场景需要使用推的方式,推是同步处理;
    2. 拉的方式可以周期性批量处理,减少网络通信量,消费者可以根据自身能力来调节拉取量;
    3. 需要同步事件的消费者众多时,使用推送方式容易阻塞,增加推送者重试的负担,如消费者处理慢或是网络原因;
    推是同步处理,拉是异步处理。
    2021-02-02
    4
  • 可不可以结合具体的业务场景分享一下 eBay 里面是怎么做这些组件的技术选型的? 比如说是用了开源的还是自研的?

    作者回复: 这位同学你好。我在第4节课提到过,核心系统需要自研。账务系统是支付业务最核心的组件之一,虽然自研投入高,但是回报也高,因此是一个值得自研的系统。

    2021-02-01
    1
  • tt
    如果选择从主节点复制数据,为了避免增加主节点的压力,是不是选择推模式比较好,这样主节点可以选择在空闲的时间(片)内调度推送任务的执行时间。但这样会增加复制的延时——由于忙,无法及时推送。

    如果是选择从从节点上复制事件对列,那么可以选择拉模式,这样由于从节点负载比较轻,拉去请求可以及时被响应。

    我觉得最简单的就是增加消息中间件,让写模式状态机把消息发布到消息中间件上去,由别人来订阅。
    2021-02-01
    2
  • Kyle Liu
    必须要无脑赞一个,分布式这方面在国内似乎没有什么好的资料,老师可以推荐点靠谱的资料吗。

    作者回复: 小编指路专栏加餐2的书单,希望有帮助。

    2021-02-08
收起评论
4
返回
顶部