tikv 存储架构的问题, 有这个文章, 对于multi group raft这种模式, region 在集群中均匀分布, 集群规模越大, 丢数据的可能性越大(例如三副本时同时坏两个tikv节点).
它强调了两点:
我的疑问是, 由于tikv region是随机分布, 如果布署大集群, 会遇到整体可用性降低的问题, 在这一块有什么规划吗?
就tidb来说
如果数据确实很重要可以考虑副本数量从3增加到5，提高可用性。
增加副本数量可以集群整体增加，也可以使用PlacementRules in SQL，灵活的指定某个表副本数，存放的位置。
关于集群规模越大, 丢数据的可能性越大这个问题，在tidb官方课程中也是有介绍的
规划取决于业务上对数据的重视程度，副本数是可选的，节点数也是一样的，这是两个方向的取舍。
另外楼上描述的 调度策略，也可以满足不同的业务场景对于数据存在不同节点的规则定义。
如有疑问不如实践尝试一下，可以强调一下，即使是 三副本，三节点的情况下，掉了二个节点，数据也没丢…
这个时候需要有效的步骤来激活，保证集群的可用性…
通过调度与副本数控制应该能避免吧，比如指定region的host和增加副本数等方式
3副本raft协议，2个写入成功就返回成功，第三个没写入成功时候前2个写成功的挂掉了，真会丢数据。虽然可以恢复，数据一致性就难说了
+1， 不过确实集群机器越多同时坏两个节点的概率越大，只能评估成本/可用性哪个更重要，看需不需要增加副本数来解决。
不过，这么来讲，其实所有的分布式数据库都有这种问题，即便你不用分布式数据库，如果数据量真的特别大，分库分表用上千台MySQL来组成大的集群，这个概率其实是一样的。不管什么架构都逃不了
感谢大家的回复. PolarDB这篇文章, 主要观点在于在集群规模比较大的情况下, 如何做好故障的影响范围.
它举例说明了, 三副本的情况下, 同时挂掉两台机器, 如何不影响或少影响region可用性.
三副本挂2个 只要要求多数一致的都保证不了region可用，但不一定就数据丢失，比如tidb 就有unsafe recover从单副本恢复数据。但是要是5副本，那挂2个就没问题，这个问题可以再改成： 5副本挂掉3个机器会发生什么？那就7副本。
哦。我想说的是 三副本情况下, 有 N个tikv 实例, 同时坏两个实例的概率随着N的变大布升高, 同时故障的情况下, 落在这两个机器上的region就不可用.
从是否丢数据的角度来说, 丢数据的可能性随着N的变大就变高.
N变大，坏2个概率也就变大，region不可用的概率也会变大。丢失数据和这没关系，剩最后一个region副本了，那他的数据和Leader是完全同步的或者他原来就是leader 就不会丢数据(工具没问题前提下)，如果不是完全同步那就会丢。
“丢数据的可能性随着N的变大就变高” 的确是这样的，整体可靠性随着N增加会下降
3个坏2个肯定概率比100个坏2个的概率小多了，但是3个坏2个里面同一个region的3个副本坏2个的概率100%，但是100个坏2个里面同一个region的3个副本坏2个的概率也小多了啊。。。。其实整体可靠性并不见得下降
只有我看迷糊了么？三副本坏两个节点，这是两个不同的指标吧。
三副本三节点坏两个节点，就不可用了，但是三副本五节点坏两个节点，还是可用的。
这样来说，应该是可用性高了吧。
三副本五节点坏两个节点，大部分region变成单副本了，集群可以算是半瘫痪了
所以节点坏了不管嘛，地主家也不能这么浪费呀~
不好说，监控不到位一个节点挂了都没发觉，过一阵再坏一个就凉了
我看都在说奇数节点奇数副本，如果是偶数节点奇数副本呢？
因为官方建议就是奇数~
只要节点数大于副本数，奇数节点偶数节点无所谓吧
tidb三副本挂2台数据库直接停止服务，并不存在所谓还能继续跑业务的事，因为tidb是强一致性的.
CAP理论，要强一致性就得放弃可用性