分布式金融架构课
任杰
eBay支付账务系统负责人,前蚂蚁金服架构师
立即订阅
1442 人已学习
课程目录
已更新 22 讲 / 共 23 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 如何成为金融级人才?
免费
金融业务与系统 (6讲)
01 | 业务初探:扫了二维码之后发生了什么?
02 | 原理解读:如何理解第三方支付的业务逻辑和系统组件?
03 | 产品大观:不同金融业务都有哪些技术实现要点?
04 | 领域驱动设计(上):如何设计金融软件顶层架构?
05 | 领域驱动设计(下):如何设计统一的金融业务模型?
答疑集锦(一) | 思考题解析与外汇架构知识拓展
系统正确性保障 (7讲)
06 | 计算输入的正确性:怎么选择正确时间的数据?
07 | 计算过程的正确性:如何设计正确的数据处理架构?
08 | 计算结果的正确性:怎么保证计算结果是正确的?
09 | 数据传输的质量:金融业务对数据传输有什么要求?
10 | 数据存储的合理性:金融业务可以不用关系型数据库吗?
11 | 系统优化:如何让金融系统运行得更快?
答疑集锦(二) | 思考题解析与账务系统优化
分布式正确性及高可用 (8讲)
12 | 正确性分级(上):单机无备份有哪几种不同的一致性?
13 | 正确性分级(中):多机无容灾有哪几种不同的一致性实现?
14 | 正确性分级(下):多机有容灾有哪几种不同的一致性?
15 | 分布式正确性的存在性(上):什么情况下不存在分布式共识算法?
16 | 分布式一致性(下):怎么理解最简单的分布式一致性算法?
17 | 正确性案例(上):如何实现分布式的事件溯源架构?
18 | 正确性案例(中):常见分布式数据方案的设计原理是什么?
19 | 正确性案例(下):如何在运行时进行数据系统的动态分库?
分布式金融架构课
15
15
1.0x
00:00/00:00
登录|注册

18 | 正确性案例(中):常见分布式数据方案的设计原理是什么?

任杰 2021-02-03
你好,我是任杰。这一讲我想和你聊一聊常见的分布式数据系统的设计原理。
所有的业务系统归根到底都需要处理数据,因此从本质上来讲都是数据系统。业务系统和一般数据系统只是在处理数据的逻辑上有所不同,它们对于数据的存储、读取、容灾等都有极大的相似之处。
因此,我希望在学完这节课之后,你既能了解常用数据系统的运作原理,更好地使用它们,同时也能举一反三,在今后设计金融系统架构的时候能借鉴一些思路。
大部分的原理我在前面的课已经讲过了,关键之处我还会再次提示,如果有不清楚的内容,你可以回到对应的文章去复习一下。

Redis

我们先从最简单的 K/V 存储开始。Redis 出现之后,一举取代了 Memcached,成为首选的基于内存的 K/V 解决方案。Redis 的核心竞争力是速度快,那我们就来分析一下,为什么 Redis 会拥有速度上的优势呢?
首先,我们看看 Redis 处理数据的方式。Redis 默认用单线程处理所有数据。
单线程是一种能优化延时的解决方案,不过单线程虽然适合处理数据,但是不一定适合 I/O。同一时刻可能会有多个客户端在访问 Redis,如果用多线程处理的话,就会出现多线程造成的加锁冲突。
这时候,Redis 用了我们在第 11 节课讲网络优化时提到的 epoll 方法,用较少的计算资源来支持大量的 I/O 并发。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式金融架构课》,如需阅读全部文章,
请订阅文章所属专栏
立即订阅
登录 后留言

精选留言(3)

  • Troy@InfoQ_0a1dfd515153
    老师课程前半部分比较多关于金融系统的业务逻辑,后面倒是比较偏技术实现。有没有考虑再出一系列课程专门介绍更多金融系统的业务逻辑、牵涉到的机构。本身不是从事金融相关技术,对真实世界金融系统的运作还不是很了解
    2021-02-04
  • 小动物
    对课后问题是否可以换个角度来思考。数据库无非就是支持数据查询、修改等等操作。而我们平时的业务系统对外暴露的也是查询、修改等等操作。从外部来看,两者行为上是类似的。
    那么课后的问题就可以更换为,在分布式的情况下如何保证业务的正常运行。似乎就会熟悉些。
    比如缓存我们使用Redis、单机事务使用mysql、索引分区配置等等。
    2021-02-03
  • tt
    作答如下,有的就是一些堆砌,逻辑还不是很顺。

    首先,数据库是有状态的,最终目的是为了存储数据,基于老师在这节课中的内容,应该有以下的几个考虑:

    • 稳定性(高可靠、高可用)
    • 正确性(各种一致性与隔离级别)
    • 速度。这里把速度对应到性能,性能又做出如下的分解:
    ○ 读性能
    ○ 写性能
    ○ 存储空间

    1、表存储

    表存储主要目的是存储数据。这层不考虑事务(即正确性)、读写性能(即速度)。主要考虑数据量及存储空间。为什么呢?参考对MYSQL的理解,为了保证写入性能以及稳定性(crash safe),用的是WAL(write ahead log);为了保证读取性能,用的是索引。

    同时,在具体操作数据时,是以页为单位进行的,且不是直接在硬盘上进行,而是将数据映射到内存页中,在内存页中进行修改后,然后刷盘。对内存页修改的依据一般就是顺序写的日志如redolog,因为日志里记录的是各种操作,我的理解就是复制状态机用到的命令。

    此外,写的正确性还涉及到索引,如唯一索引就必须对数据做校验以满足唯一性。

    应对大数据量,就是分片了。数据分片后也会提高性能。数据分片底层可以用分库分表,也可以采用各种线程的KV存数,比如这里的ROCKSDB。

    分片之间需要同步数据,同步数据也是基于日志的,即老师讲过的

    2、主索引和二级索引

    索引主要是为了提高读取性能。读取数据的目的又有两种:在线交易(OLTP)和数据分析(OLAP),应该根据数据库的使用场景不同,设计不同的索引结构。

    数据的存储分片后,对应的索引应该如何存储呢?能想到的是索引和对应的存储采用一样的分片策略,每个存储节点上都有自己的索引,然后在主节点(有主节点,就默认了只有它对外提供服务)上建立一个数据和节点的对应关系(这个就是主索引么?)。对于跨分片的查询,将查询分发到相应节点上。

    这里就成了用多台MYSQL,然后前面加一个数据库中间件,比如SHARDING SPHERE。

    3、缓存

    先做一个假设:缓存就是用空间换时间,且只缓存热点数据。那么需要缓存的数据就是少的,所以要不直接使用REDIS吧。缓存和DB的一致性就使用常用的哪些,比如cache aside之类的。

    4、表的复制和容灾

    将日志通过消息队列发送到其余分片,消息队列后对接底层存储本身支持的复制机制。

    5、单机事务

    如果底层支持,如为MYSQL,则用底层的事务。如果底层不支持,在服务层利用REDIS、zookeeper来实现。

    6、分布式锁

    用REDIS实现活用ZOOKEEPER等实现,前者应该性能更好吧。

    7、分布式事务

    可以用:

    • 2PC,性能太差
    • TCC,对业务侵入较多
    • 或者利用实现了线性一致性的系统。
    • 或者在业务层实现,即用REDIS实现的分布式锁。

    分布式事务就是要做到分布式的一致性。可以用锁来实现,锁能实现是因为可以用它实现冲突可串行化。

    但是用锁来解决冲突,性能太低。分布式事务是要解决隔离性和一致性,所以还是要根据操作类型采用对应的手段:

    • 解决读写冲突:采用MVCC,通过版本来解决重读——使用没有冲突的数据版本,自然就没有哦冲突了。
    • 解决写写冲突:
    ○ 如果压力不是很大,可以用乐观协议;
    ○ 如果压力很大,还是用悲观锁
    2021-02-03
收起评论
3
返回
顶部