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

王磊



该思维导图由 AI 生成，仅供参考

你好，我是王磊，你也可以叫我 Ivan。今天，我们要学习的是数据复制。
数据复制是一个老生常谈的话题了，典型的算法就是 Paxos 和 Raft。只要你接触过分布式，就不会对它们感到陌生。经过从业者这些年的探索和科普，网上关于 Paxos 和 Raft 算法的高质量文章也是一搜一大把了。
所以，今天这一讲我不打算全面展开数据复制的方方面面，而是会聚焦在与分布式数据库相关的，比较重要也比较有意思的两个知识点上，这就是分片元数据的存储和数据复制的效率。
分片元数据的存储我们知道，在任何一个分布式存储系统中，收到客户端请求后，承担路由功能的节点首先要访问分片元数据（简称元数据），确定分片对应的节点，然后才能访问真正的数据。这里说的元数据，一般会包括分片的数据范围、数据量、读写流量和分片副本处于哪些物理节点，以及副本状态等信息。
从存储的角度看，元数据也是数据，但特别之处在于每一个请求都要访问它，所以元数据的存储很容易成为整个系统的性能瓶颈和高可靠性的短板。如果系统支持动态分片，那么分片要自动地分拆、合并，还会在节点间来回移动。这样，元数据就处在不断变化中，又带来了多副本一致性（Consensus）的问题。
下面，让我们看看，不同的产品具体是如何存储元数据的。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

分布式数据库的数据复制是一个复杂而重要的技术领域。本文从分片元数据的存储和数据复制效率两个方面展开讨论。首先，介绍了静态分片和动态分片的存储方式，以及TiDB和CockroachDB两种不同的设计思路。TiDB采用无服务状态的设计，通过Placement Driver节点管理元数据，而CockroachDB则采用去中心化的Gossip协议，实现了强一致性的分布式数据库。其次，对比了Raft和Paxos在数据复制效率上的差异，以及Raft的一些优化手段。文章指出，副本数量和节点规模对复制协议的选择有重要影响，副本少时适合采用Paxos、Raft等协议，而副本多时更适合采用Gossip协议。通过对这两个方面的讨论，读者可以快速了解分布式数据库数据复制的关键技术特点。同时，文章还介绍了Raft的性能缺陷和TiDB对Raft的性能优化方法，以及分布式数据库存储容量的思考题。整体而言，本文深入浅出地介绍了分布式数据库数据复制的关键技术特点，对读者理解该领域具有重要参考价值。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《分布式数据库 30 讲》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(23)

最新
精选

真名不叫黄金
我认为分布式数据库的瓶颈可能在于两个方面: 1. 元数据，元数据过多的情况下，可能需要多层查找，才能找到数据的节点，由此降低了性能。 2. 心跳包，如果网络中太多节点，那么心跳包也会占用相当多的带宽，影响IO性能
作者回复: 说的很好，点赞
2020-08-26

26
tt
我觉得容量上限主要受制于业务场景，为了提高性能需要增加分片，但是分片多了以后，为了达到一致性的要求，节点太多影响通讯和数据复制的成本，这两个方面权衡一下就决定了容量的上限
作者回复: 这个思路非常赞，我再补充一下，集群规模增大对于局部业务来说，可能是不受影响，因为局部业务的分片和节点说可能并未增多。但是元数据是所有业务都会访问的，就会收到规模增大的影响。
2020-08-24
3
12
扩散性百万咸面包
老师看看我对Multi Raft的理解对不对。一个Raft Group存储一个Region的多副本。例如TiDB默认副本数是３，那么一个Raft Group就是３个副本。同时一个节点可能有上千个Region（一般这些Region都不互为副本），每一个Region都属于一个Raft Group，那么也就是说这个节点可能参与上千个Raft Group。每个Raft Group又会选举出一个节点作为Raft Leader，负责写入数据。
作者回复: 基本正确，我再提示一下。Region之间的数据是不同的，所以任何情况下Region间都没有主副本关系。
2020-08-24
2
5
Geek_81c7c9
引用一下王老师对PGXC和NEWSQL的观点： PGXC（raft）有稳定的工程实现； NEWSQL（paxos）有更先进的设计思想；从更容易落地的角度出发，raft确实更适合；从更长远、更能有效规避潜在风险的角度出发，还是得上paxos，毕竟两大国民APP（支付宝ob、微信PhxPaxos）背后都是它对吧~
作者回复: PGXC并没有使用Raft，还是基于单体数据库的主从复制，NewSQL产品则是在Raft和Paxos中选择，多数是Raft。
2020-10-17
3
4
扩散性百万咸面包
老师，看到你的文章中对比了Gossip和Raft/Paxos这种算法，能说明一下如果Gossip共识时间更短，为什么TiDB等数据库不选择呢？为什么它更适合多节点？是因为它把网络I/O分散到多个节点上吗？可是这也带来了一定的串行性呀！ BTW, Gossip达成共识要比Raft和Paxos要快么？
作者回复: Gossip达成共识不比Raft更快，CRDB选择它，因为它不是广播机制。而节点规模很大是广播机制的通讯成本太高。TiDB和其他数据库的元数据节点规模很小，所以适用Raft
2020-09-09
2
4
黎
佩服这些协议的理论提出者，更佩服协议的工程实现者
作者回复: 嗯嗯，所以学习的过程也是收获感满满
2020-08-24

4
淡漠落寞
老师，想请教一下关于cockroachdb里的gossip相关的问题： 1 客户端是如何知道要往哪个节点发送请求的呢？ 2 range的分裂场景下，节点的分片元数据信息的变更和节点的实际数据的迁移的先后顺序是怎么样的呢？
作者回复: 1.客户端访问节点时并不考虑节点的元数据情况，是由不同的负载均衡策略决定。 2.多数节点的元数据变更在实际数据迁移之后。根据gossip协议原理，数据一致性收敛会有个过程。
2021-06-27

1
OliviaHu
老师，咨询下，CockroachDB是如何判断R1分片的元数据过期的呢？全局时间戳吗？
作者回复: 全局时间戳貌似解决不了这个问题，R1过期是因为与实际数据存储不符，而原来承载R1的节点会记录R1的去向，可以再次路由
2020-08-24

1
武功不高
额，全是新知识，有点懵懵，需要好好消化消化……
作者回复: 嗯，慢慢来，有问题就留言讨论
2020-08-24

1
piboye
hbase 的 root 表位置放到zk上，root 表找到meta表，再找到region表，这种方式好像和老师说的不同哦。 hbase不是分布式数据库，所以可以不一样的实现？
作者回复: zk也是一个保证数据高可靠存储的小集群呀，和etcd是一个道理。
2020-08-24



收起评论