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