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

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

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

Redis

我们先从最简单的 K/V 存储开始。Redis 出现之后,一举取代了 Memcached,成为首选的基于内存的 K/V 解决方案。Redis 的核心竞争力是速度快,那我们就来分析一下,为什么 Redis 会拥有速度上的优势呢?
首先,我们看看 Redis 处理数据的方式。Redis 默认用单线程处理所有数据。
单线程是一种能优化延时的解决方案,不过单线程虽然适合处理数据,但是不一定适合 I/O。同一时刻可能会有多个客户端在访问 Redis,如果用多线程处理的话,就会出现多线程造成的加锁冲突。
这时候,Redis 用了我们在第 11 节课讲网络优化时提到的 epoll 方法,用较少的计算资源来支持大量的 I/O 并发。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式数据系统设计原理涉及Redis和RocksDB两种常见的分布式数据方案。Redis采用单线程和epoll处理数据,异步容灾通过牺牲一致性来提高消息返回速度,同时使用RDB和AOF实现定期状态备份。而RocksDB基于SSTable和LSM树,实现了快速写入和基于文件的K/V查询能力。LSM树的写入速度快,但查询速度慢,适合对写入速度要求高的场景。这些方案在分布式系统中能提供异步容灾能力,绕开内存大小限制,同时也存在一致性和速度的权衡。 Spanner是Google在2012年公布出来的一个全球性分布式关系型数据库,采用Paxos算法实现日志文件同步到多台机器,并通过日志文件实时同步彼此的状态,实现多个数据库的实时状态同步。Spanner还采用原子钟实现的TrueTime API来优化事务的实现。 TiDB是国产分布式数据库的领军人物之一,基于Raft算法实现日志文件的全序广播,同时通过TiKV和TiFlash组件实现了分布式K/V存储和基于列存储的数据查询功能,实现了读写分离的优化。 这些技术特点为读者提供了对分布式数据系统设计原理的深入了解,以及在实际应用中的选择和权衡。Spanner和TiDB的设计思路和优化方案为分布式数据系统的发展提供了重要的参考和启发。

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

全部留言(3)

  • 最新
  • 精选
  • Troy@InfoQ_0a1dfd515153
    老师课程前半部分比较多关于金融系统的业务逻辑,后面倒是比较偏技术实现。有没有考虑再出一系列课程专门介绍更多金融系统的业务逻辑、牵涉到的机构。本身不是从事金融相关技术,对真实世界金融系统的运作还不是很了解

    作者回复: 这位同学你好。金融业务系列也正在筹备中,敬请期待。

    2021-02-04
    3
    4
  • 小动物
    对课后问题是否可以换个角度来思考。数据库无非就是支持数据查询、修改等等操作。而我们平时的业务系统对外暴露的也是查询、修改等等操作。从外部来看,两者行为上是类似的。 那么课后的问题就可以更换为,在分布式的情况下如何保证业务的正常运行。似乎就会熟悉些。 比如缓存我们使用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
    12
收起评论
显示
设置
留言
3
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部