分布式数据库30讲
王磊
光大银行首席数据架构师
新⼈⾸单¥19.9
2205 人已学习
课程目录
已更新 12 讲 / 共 33 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|为什么要学习分布式数据库?
免费
基础篇 (8讲)
01|什么是分布式数据库?
02|强一致性:那么多数据一致性模型,究竟有啥不一样?
03|强一致性:别再用BASE做借口,来看看什么是真正的事务一致性
04 | 架构风格:NewSQL和PGXC到底有啥不一样?
05 | 全局时钟:物理时钟和逻辑时钟你Pick谁?
06 | 分片机制:为什么说Range是更好的分片策略?
07 | 数据复制:为什么有时候Paxos不是最佳选择?
08 | 基础篇大串讲:重难点回顾+思考题答疑+知识全景图
开发篇 (3讲)
09|原子性:2PC还是原子性协议的王者吗?
10 | 原子性:如何打破事务高延迟的魔咒?
11|隔离性:读写冲突时,快照是最好的办法吗?
分布式数据库30讲
15
15
1.0x
00:00/00:00
登录|注册

11|隔离性:读写冲突时,快照是最好的办法吗?

王磊 2020-09-02
你好,我是王磊,你也可以叫我 Ivan。我们今天的话题要从多版本并发控制开始。
多版本并发控制(Multi-Version Concurrency Control,MVCC)就是通过记录数据项历史版本的方式,来提升系统应对多事务访问的并发处理能力。今天,几乎所有主流的单体数据库都实现了 MVCC,它已经成为一项非常重要也非常普及的技术。
MVCC 为什么这么重要呢?我们通过下面例子来回顾一下 MVCC 出现前的读写冲突场景。
图中事务 T1、T2 先后启动,分别对数据库执行写操作和读操作。写操作是一个过程,在过程中任意一点,数据的变更都是不完整的,所以 T2 必须在数据写入完成后才能读取,也就形成了读写阻塞。反之,如果 T2 先启动,T1 也要等待 T2 将数据完全读取后,才能执行写入。
早期数据库的设计和上面的例子一样,读写操作之间是互斥的,具体是通过锁机制来实现的。
你可能会觉得这个阻塞也没那么严重,磁盘操作应该很快吧?
别着急下结论,让我们来分析下。如果先执行的是 T1 写事务,除了磁盘写入数据的时间,由于要保证数据库的高可靠,至少还有一个备库同步复制主库的变更内容。这样,阻塞时间就要再加上一次网络通讯的开销。
如果先执行的是 T2 只读事务,情况也好不到哪去,虽然不用考虑复制问题,但是读操作通常会涉及更大范围的数据,这样一来加锁的记录会更多,被阻塞的写操作也就更多。而且,只读事务往往要执行更加复杂的计算,阻塞的时间也就更长。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式数据库30讲》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(1)

  • 真名不叫黄金
    我认为 Spanner 的时钟误差会影响到事务吞吐量:
    由于 Spanner 是 External Consistency 的,也就是可线性化(linearizable)的,那么只要两个事务需要读写的数据中有相交的数据,那么它俩的提交时间平均间隔至少是7ms,因为置信区间平均是7ms,那么在这个置信区间内是不能 commint 2 个读写了某个相同数据的事务的,否则就会打破可线性化,因为两个事务不一定分得出先后。因此 Spanner 在单位时间内的事务吞吐量是被时钟误差限制的,时钟误差越小,吞吐量越高,误差越大,吞吐量越低。
    并且我也猜测,以下两种情况是的事务吞吐量是不被时钟误差影响的:
    1. 如果两个事务操作的是完全不相交的数据,那么它们的 commit time 是可以重合的,因此时钟误差限制的仅仅是操作相交数据的事务的吞吐量。
    2. 如果某个事务是只读事务,那么也不受限制,因为只读是基于快照的,其 commit timestamp 并没有意义,因此不需要与读写事务抢时钟。

    受限于既有知识,猜测可能有误,仅仅是交流~

    作者回复: 说得很好,基本都正确,点赞。我在第12讲介绍了Spanner的完整处理过程,可以参考。

    2020-09-02
    1
收起评论
1
返回
顶部