副本放置算法
1、raft协议原理
raft
2、单个shard的复制
raft-single
3、Raft group组
raft-group
在一定情况下，copyset的数量不是越多越好，在恢复时间确定的情况下，找到合适的copyset的数量可以降低数据丢失的概率。为了提高存储系统数据可靠性，首先在系统允许的成本范围内选择合适的副本数，再次在系统设计中我们首先优先考虑加快数据恢复时间，在此基础上减小系统的copyset数量。使得在既定的成本下达到尽可能高的可靠性。参考论文《Copysets:Reducing the Frequency of Data Loss in Cloud Storage》，该论文中的实验数据显示，在facebook HDFS集群上作实验，为了有效降低数据丢失概率，数据放置算法，从原来的Random Replicaiton更改为copyset Replication 算法，实验结果说明可 将FaceBook HDFS集群1%节点故障时的数据丢失概率从22.8%降低道0.78%。
在大型集群中，多个节点的同时丢失具有很高的数据丢失概率。例如，考虑使用副本数为3的100个节点的群集，其shard数范围约为10k。同时丢失2个或更多节点具有很高的数据丢失概率，因为可能存在10k shard之外的shard，而该shard在2个丢失的节点上具有3个副本中的2个。在存在多节点故障的情况下，copyset算法可以显着降低了数据丢失的可能性。
根据系统节点数，和副本数量，进行多个轮次的计算，每一轮次把所有节点按照副本数划分为 N／R 个copyset。每次确保其中的copyset 不与当前和之前所有轮次中已经产生的copyset相同，最后数据写入的时候，选择一个copyset 写入即可。 由于每个排列会吧S(Scatter Width) 增加R-1,所以 算法执行P = S/（R-1） 次， K(CopySet数量) = P (N/R) = S/(R-1) (N/R)。
复制集将群集分为不相交的节点集。每组的大小将基于使用的副本数。为每个副本创建单独的副本集。shard应该更喜欢在副本集中分配其副本，而不是在副本集中散布其副本。
所以有两个主要组成部分：
1.管理副本集（哪个节点属于哪个副本集）副本集分配应考虑节点的位置，以便不会丢失位置容错能力。将节点分配给副本集时，应考虑添加/删除/损坏的节点。
2.重新平衡范围中的所有副本，以尽最大努力将其驻留在单个副本集中。将副本重新平衡到副本集很重要，但是某些属性（如用户设置的约束）应优先于副本集。
副本集最初将是一个选择加入功能（基于群集设置），并且实现为分散宽度为replication_factor - 1。
管理副本集
该集群将被分为多个副本集。对于群集中的每个副本，将生成单独的副本集。
副本的副本集的要求是
1.对于rf -1的散布宽度，副本集之间的节点应该没有重叠，并且对于散布宽度> = rf（其中rf是复制因子），应使重叠节点最小化。
2.副本集应具有本地容错能力
3.副本集应重新平衡节点的添加/删除/故障。
为系统中使用的每个副本生成副本集。如果对齐了不同副本的副本集，则可以提供更好的容错能力。
副本分配策略采用最佳副本集分割分配算法。
特定的副本的副本集的最佳分配可以如下进行：
1.计算 num_copysets = floor(num_stores/replication_factor)
2.基于机架等特定配置进行存储排序
3.分配副本集到存储，采用轮询调度方案（Round-robin）
例如，有如下存储情况：
Rack1：S1 S2 S3
Rack2: S4 S5 S6
Rack3: S7 S8 S9 S10
复制因子是3的副本集将创建：
num_copysets = 10/3 = 3
CS1: S1 S4 S7 S10
CS2: S2 S5 S8
CS3: S3 S6 S9
Swap
在源副本集和目标副本集之间进行交换，以确保源副本集的多样性增加，而目标副本集的多样性确实减少（或者如果减少，它仍然>复制因子）。
基于源副本集和目标副本集中存在的位置，在源副本集和目标副本集之间进行存储交换。交换所需的条件是：
1.源副本集的多样性<复制因子。这意味着源副本集在特定位置具有两个存储。这些付出之一将是源交换候选者。
2.目标副本集具有源副本集中不存在的局部性（我们称此目标局部性）。来自该地区的商店将成为目标交换候选人。
3.以下之一是正确的
4.目标副本集中不存在源交换候选的位置。
目标副本集
1.在目标位置有两个存储。
2.具有多样性>复制因子。
上面的多样性是指副本集中的位置数量。
上面的要点3确保目标副本集的多样性不会减少（或者如果减少，它就不会低于复制因子）。
进行交换的单个迭代会考虑所有(n choose 2)副本集组合，其中副本集n的数量为。这些迭代将继续进行，直到无法进一步改善所有副本集的多样性之和为止（整个迭代都没有找到交换对象）。
例如，考虑以下我们拥有存储的情况：
Rack1: S1 S2 S3
Rack2: S4 S5 S6
Rack3: S7 S8 S9
Rack4: S10 S11 S12 S13
最初副本集的分配：
CS1: S1 S5 S9
CS2: S2 S6 S10
CS3: S3 S7 S11
CS4: S4 S8 S12 S13
如果存储S6被删除，步骤2之后（将存储分配到相同的副本集ID，直到大小达到rf），我们有了
CS1: S1 S5 S9
CS2: S2 S10
CS3: S3 S7 S11
CS4: S4 S8 S12
再通过添加剩余存储来填充空白点之后
CS1: S1 S5 S9
CS2: S2 S10 S13
CS3: S3 S7 S11
CS4: S4 S8 S12
交换之后（由于CS1和CS2之中CS2有两个存储来自与rack4）
CS1: S1 S5 S13
CS2: S2 S10 S9
CS3: S3 S7 S11
CS4: S4 S8 S12
这种交换策略可能无法实现最佳的多样性，但会尝试确保副本集中的每个位置都不同。
副本集重新生成
考虑用于副本集分配的存储列表将是当前的实时存储。实时存储的计算方式与分配器检测实时存储的方式相同（但不会排除受限制的存储。）如果存储列表稳定且未更改3个心跳数（每个心跳声都有），则会重新生成副本集。间隔10秒）。
副本集分配可以作为原型保留在分布式存储层中。最小化数据移动的副本集策略要求保留副本集（它要求先前的状态为全局状态并在重新启动后仍然有效）。群集中最低的活动节点ID将是管理（持久）副本集。其他节点将定期（每10s）缓存持久化的副本集，并将其用于重新平衡。
仅当存储列表更改时，副本集才会重新生成（并保留）。在稳定状态下，所有节点将定期读取持久化的副本集，而无需重新生成并持久化新的副本集。
对于RF = 3，群集可以容忍每个副本集中一个节点的故障。例如，在最佳情况下（对于RF = 3），一个100个节点的群集可以承受33个节点的同时故障，而不会造成任何数据丢失。
重平衡范围
范围需要重新平衡以包含在副本集中。
HUBBLE目前使用两种范围再平衡器：
1.复制对略
2.存储池管理器
对于平衡使用评分功能：
1.确定范围内要用于新副本的存储
2.当范围超过所需副本数时要删除的副本
3.副本必须从一个存储移动到另一个存储，该范围的结果得分将更高
计分功能考虑一下因素（按优先级顺序排列）：
1.区域约束：在某些区域中具有某些表的约束
2.磁盘已满：检查存储是否太满
3.多样性分数差异：多样性分数与该范围内存在的副本数所处机架的数量成正比。它基于地点的nC2多样性分数，其中n是副本的数量。
4.收敛分数差异：收敛分数用于避免移动shard，移动shard的移动会导致shard的统计信息偏离全局平均值。
5.平衡分数差异：平衡分数是节点的标准化利用率，当前它考虑范围的数量，平衡分数较低的节点是首选。
6.范围计数差异：范围计数较低的存储是首选。
副本集分数
为了将shard重新平衡到副本集中，新的副本评分将添加到分配器中。区域约束和磁盘填充比副本集得分具有更高的优先级。
由于副本集分配考虑了多样性，因此可以将其优先级置于多样性得分之上。
如果满足一下条件，则该副本集得分较高：
1.Shard完全包含在副本集中
2.Shard所在的副本集未得到充分利用。我们希望每个副本集均被加载。如果shard在拷贝集中完全包含x我们应该完全移动到副本集y中。如果副本集y的节点有更低的负载，更多的可用磁盘空间等情况。
以上为副本机制，「分布式技术专题」是国产数据库hubble团队精心整编，专题会持续更新，欢迎大家保持关注。