对于分布式存储系统，我们都会使用多副本的机制来保证数据的安全性。譬如对于 TiKV 来说，我们默认会使用 3 个副本，如果需要更高等级的安全性，譬如在银行领域，我们则会使用 5 个副本。但无论使用几个副本，我们都会面临一个问题，我们如何在集群中放置这些副本。
机器都是有寿命的，磁盘，内存等硬件在运行的时候也时不时会坏掉。假设现在我们使用 3 个副本，有 N 台机器，如果同时有 3 台机器坏掉，而悲催的是刚好 3 个副本在这 3 台机器上面，那么我们就会面临数据丢失问题。所以我们需要尽量减少数据丢失的概率。
Random replication
最简单的做法就是选择任意 3 台机器来放置副本，但是这个策略其实不好。假设机器坏掉的概率是 1%，对于 3 副本来说，同时坏掉的概率是 0.0001%，看起来这个是很低的，但实际中，我们不光只有一份数据。
在 TiKV 里面我们会将数据切分成多个 region，每个 region 对应一份数据，在实际生产环境中，region 数量是非常多的，一些集群都已经过了百万了，这时候如果有 3 个节点同时损坏，一些 region 副本全丢掉的概率会非常的大。
下图是 Copysets paper 里面给出的数据，可以看到，那么随着节点数的增多，使用随机复制方式的 3 副本掉数据的概率会急剧的增大：
Copysets replication
为了解决 Random replication 的问题，有人提出了 Copysets，也就是论文 Copysets: Reducing the Frequency of Data Loss in Cloud Storage，相比于使用 random 方式，Copysets 引入了 scatter width，将整个集群节点进行分组，然后在分组的集合里面选择节点进行复制。
Copysets 的算法其实比较简单，假设集群数量是 N，复制因子是 R（其实就是选择几个副本），scatter width 是 S，那么：
- 创建
S / (R - 1)个节点排列 - 将每个排队分成 R 组
- 随机选择一个节点当成副本的 primary 副本
- 在分组的包含 primary 节点的集合里面随机选择 secondary 副本
譬如，假设我们有 9 个节点，R 是 3，而 S 是 2，那么就有 2 / (3 - 1) = 1 个排列，譬如 [1, 6, 5, 3, 4, 8, 9, 7, 2]，然后我们分成 3 组，也就是 [1, 6, 5], [3, 4, 8], [9, 7, 2]。
对于 3 副本，假设我们选择 1 作为 primary 副本存放的节点，那么剩下两个 secondary 副本只能在 6 和 5 上面选取。
使用 Copysets，能有效的降低丢失数据的概率，根据 Paper 里面描述，在 5000 个节点下面，如果有 1% 的节点同时挂掉，random 丢失的概率是 99.99%，而 Copysets 则是 0.15%。
Tiered Replication
当然，copysets 并不是银弹，它并不能解决集群动态扩容的问题，于是 copysets 的作者，继续研究了另一个解决方案，也就是 Tiered replication，Paper 是 Tiered Replication: A Cost-effective Alternative to Full Cluster Geo-replication。
Tiered Replication 的原理其实也比较简单，仍然有 Copysets 的概念 scatter width S，会将整个集群分成多个 Copysets，每个 Copysets 的大小是 R，对于每个节点，必须保证它至少在 S 个 Copysets 里面。另外，Tiered Replication 里面也有 primary 和 backup 节点的区分，通常两个副本会放在 primary 节点里面，而第三个副本则会放到 backup 节点里面。
Tiered Replication 的算法比较简单，大概来说：
- 所有节点开始的 scatter width 是 0，也就是没有属于任何 Copysets。
- 创建一个 Copysets，选择最小 scatter width 的 R 个节点加进去。
- 重复上面的过程，直到所有的节点的 scatter width 至少是 S。
详细的算法可以看 Paper，而源码在这里，使用起来还是很简单的，譬如：
# not rack aware
>>> trepl.build_copysets(['node1', 'node2', 'node3'], R=2, S=1)
[['node1', 'node2'], ['node1', 'node3']]
# rack aware, node1 and node2 can not share a copyset since they're in
# the same rack
>>> rack_map = { 'node1': 'rack1', 'node2': 'rack1', 'node3': 'rack3' }
>>> trepl.build_copysets(
rack_map.keys(), R=2, S=1,
checker=trepl.checkers.rack(rack_map),
)
[['node1', 'node3'], ['node2', 'node3']]
对于集群的动态更新，譬如新加入一个节点，就直接按照上面的算法，将这个节点加入到不同的 Copysets 里面，直到这个新加入的节点的 scatter width 为 S。而对于删除节点，一个简单的做法就是将包含这个删除节点的 Copysets 干掉，而在这些 Copysets 里面的其他正常节点的 scatter with 也会减少，然后会创建新的 Copysets 替换老的。在老的 Copysets 里面的正常副本可能会重新复制到其他节点上面。
总结
说了这么多，对 TiKV 来说有什么借鉴意义呢？现在 TiKV 是通过打 label 的方式来支持 Geo-replication 的，假设我有 3 个 Rack，每个 IDC 有 3 台机器，我们会给每个启动在机器上面的 TiKV 进程打上类似 rack = rack1, host = host11 这样的标签，PD 就会将 3 个副本分散到不同 Rack 的不同机器上面，但在 Rack 机器的选择上面，我们还是一个 random 算法。也就是说，即使能保证副本在不同的 Rack 上面，但随着每个 Rack 机器数量的增多，我们 3 副本同时丢失的概率就会增大，所以自然需要一个更好的副本复制策略。如果你对这方面感兴趣，欢迎联系我 tl@pingcap.com。
