分布式数据库30讲
王磊
光大银行首席数据架构师
新⼈⾸单¥19.9
2081 人已学习
课程目录
已更新 8 讲 / 共 33 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|为什么要学习分布式数据库?
免费
基础篇 (7讲)
01|什么是分布式数据库?
02|强一致性:那么多数据一致性模型,究竟有啥不一样?
03|强一致性:别再用BASE做借口,来看看什么是真正的事务一致性
04 | 架构风格:NewSQL和PGXC到底有啥不一样?
05 | 全局时钟:物理时钟和逻辑时钟你Pick谁?
06 | 分片机制:为什么说Range是更好的分片策略?
07 | 数据复制:为什么有时候Paxos不是最佳选择?
分布式数据库30讲
15
15
1.0x
00:00/00:00
登录|注册

07 | 数据复制:为什么有时候Paxos不是最佳选择?

王磊 2020-08-24
你好,我是王磊,你也可以叫我 Ivan。今天,我们要学习的是数据复制。
数据复制是一个老生常谈的话题了,典型的算法就是 Paxo 和 Raft。只要你接触过分布式,就不会对它们感到陌生。经过从业者这些年的探索和科普,网上关于 Paxos 和 Raft 算法的高质量文章也是一搜一大把了。
所以,今天这一讲我不打算全面展开数据复制的方方面面,而是会聚焦在与分布式数据库相关的,比较重要也比较有意思的两个知识点上,这就是分片元数据的存储和数据复制的效率。

分片元数据的存储

我们知道,在任何一个分布式存储系统中,收到客户端请求后,承担路由功能的节点首先要访问分片元数据(简称元数据),确定分片对应的节点,然后才能访问真正的数据。这里说的元数据,一般会包括分片的数据范围、数据量、读写流量和分片副本处于哪些物理节点,以及副本状态等信息。
从存储的角度看,元数据也是数据,但特别之处在于每一个请求都要访问它,所以元数据的存储很容易成为整个系统的性能瓶颈和高可靠性的短板。如果系统支持动态分片,那么分片要自动地分拆、合并,还会在节点间来回移动。这样,元数据就处在不断变化中,又带来了多副本一致性(Consensus)的问题。
下面,让我们看看,不同的产品具体是如何存储元数据的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式数据库30讲》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(6)

  • 武功不高
    额,全是新知识,有点懵懵,需要好好消化消化……

    作者回复: 嗯,慢慢来,有问题就留言讨论

    2020-08-24
    1
  • 扩散性百万咸面包
    老师看看我对Multi Raft的理解对不对。
    一个Raft Group存储一个Region的多副本。例如TiDB默认副本数是3,那么一个Raft Group就是3个副本。同时一个节点可能有上千个Region(一般这些Region都不互为副本),每一个Region都属于一个Raft Group,那么也就是说这个节点可能参与上千个Raft Group。每个Raft Group又会选举出一个节点作为Raft Leader,负责写入数据。
    2020-08-24
  • OliviaHu
    老师,咨询下,CockroachDB是如何判断R1分片的元数据过期的呢?全局时间戳吗?
    2020-08-24
  • piboye
    hbase 的 root 表位置放到zk上,root 表找到meta表, 再找到region表,这种方式好像和老师说的不同哦。 hbase不是分布式数据库,所以可以不一样的实现?

    作者回复: zk也是一个保证数据高可靠存储的小集群呀,和etcd是一个道理。

    2020-08-24
  • tt
    我觉得容量上限主要受制于业务场景,为了提高性能需要增加分片,但是分片多了以后,为了达到一致性的要求,节点太多影响通讯和数据复制的成本,这两个方面权衡一下就决定了容量的上限

    作者回复: 这个思路非常赞,我再补充一下,集群规模增大对于局部业务来说,可能是不受影响,因为局部业务的分片和节点说可能并未增多。但是元数据是所有业务都会访问的,就会收到规模增大的影响。

    2020-08-24
  • 佩服这些协议的理论提出者,更佩服协议的工程实现者

    作者回复: 嗯嗯,所以学习的过程也是收获感满满

    2020-08-24
收起评论
6
返回
顶部