Openck_Swift源代码分析——添加、删除设备时算法详细的实现过程

概述1 初始加入设备后、上传Object的详细流程  前几篇博客中，我们讲到环的基本原理即详细的实现过程，加入我们在初始创建Ring是执行例如以下几条命令： ?swift-ring-builder object.builder create 5 3 1   ? swift-ring-builder  object.builder  add z1-127.0.0.1:6010/sdb1 100     1 初始加入设备后、上传Object的详细流程 

前几篇博客中，我们讲到环的基本原理即详细的实现过程，加入我们在初始创建Ring是执行例如以下几条命令：

?swift-ring-builder object.builder create 5 3 1   ? swift-ring-builder  object.builder  add z1-127.0.0.1:6010/sdb1 100     ?  add z2-127.0.0.1:6020/sdb2 100   ?  add z3-127.0.0.1:6030/sdb3 100   ?  add z4-127.0.0.1:6040/sdb4 100   swift-ring-builder  object.builder  rebalance 

上面几条命令语句中，黑色的为初始创建Ring。绿色部分为向Ring中加入设备，四个设备分别位于不同的Zone中。且权重是一样的。加入完设备后须要对Ring进行平衡，以便得到replica2part2dev_ID。当中关于create add rebalance方法的详细实现过程请參考OpenStack_Swift源代码分析——Ring的rebalance算法源代码详细分析和OpenStack_Swift源代码分析——创建Ring及加入设备源代码算法详细分析两篇文章。

平衡后得到的replica2part2dev_ID 例如以下图所看到的：

             

                                                            图1 初始平衡Ring后 replica2part2dev_ID的映射

上图中第一行为分配编号(在create时输入的power为5。故为32个分区)。三个List分别代表了三个备份。上图中一个设备又同一时候相应多个不同的分区，例如以下图所看到的：

                                                                                                                               

                                        图 2 设备反映射分区

结合图1和图2。一个设备相应读个分区，这些在存储数据时，能更好的解决平衡性问题。

在得到了replica2part2dev_ID 后，如今我们向集群中存入一个对象。其步骤例如以下所看到的:

                                                                                                                                     

        

                                                 图3 存入一个对象

向集群中存入对象的流程例如以下图所看到的：

                                              

      

                                                                 图4  存入对象的流程

 存入对象时，首先依据对象的名称（account/container/object），计算其hash值。的到hash值后，取hash值的前四字节，且向右移动32-power位得到当前object相应的分区号。如15，得到分区号后。利用分区号到replica2part2dev_ID中找到此分区相应的三个设备的ID，如图1所看到的的设备ID为3 1 4 。依据这三个设备的ID，到devs中找到详细的设备，依据设备的IP。port已经存储文件的磁盘所挂载的目录，如sdb1。

将数据存如设备中。数据存入设备中的目录结构为srv/node/sdb1/objects/15/hash值后位/hash/.data文件。当中15为分区号，所以文件右移动得到的分区号为15的在该设备中都存入此目录下。

2 添加设备

假如系统执行了一段时间后。因须要存储很多其它的对象，现须要对系统进行扩展，例如以下。我们如今添加一个设备：

swift-ring-builder object.builder add z1-127.0.0.1:6050/sdb5 100

在zone1里面右添加了一个设备，其权重仍为100。加入设备后，每个设备的part_wanted值会变化，之前被分配的设备。会因新加入设备后其会超出其先须要的part_wanted故须要把他们收集回来，分配给新添加的设备，收集的详细算法实现请參见我前几篇博客，里面有详细的介绍。加入设备后，又一次对Ring进行平衡，平衡后replica2part2dev_ID例如以下图所看到的：

　　　　　　　　　　　　　　　　　　图５　加入设备后映射的变化

如上图（图中红线上部分为加入设备后的新映射，红线下部分为没加入设备前的映射）所看到的，再加入了设备后。被收集的分区是从第一个备份（第一行）先開始收集。假设第一个备份都被收集完，则再从第二个备份開始收集。如今仅仅加入了一个设备。不会收集到第二个备份的分区，故如绿框中所看到的后两个分区中分区所相应的设备ID都没有变化。图中小红框和小绿框中所看到的的，第一次平衡和新加入一个设备后平衡的分区15所相应的设备ID 当中一个由3变为5。

这样的变化，数据的一致性是怎样保证的呢？为保证因又一次移动平衡而带来的分区和设备映射的变动，Replicator在保证数据的一致性方面起到至关关键的数据。

由于Replicator这个守护进程在每个server上都有执行。故对于设备3 。它首先依据分区目录的名字获得分区号然后利用Ring类对外通过的方法。得到此分区相应的设备，此时它发现新的replica2part2dev_ID中没有了其本身。这时它会把目录名为15及其下的全部文件都删除。而对于分区15所相应是新设备5，它是怎样得到这些文件的呢？我们知道，Swift数据的同步是基于推送模式的。也就是4和3 会把其目录下的文件推送给设备5。比方设备4，其Replicator，在获得分区15所相应的设备后，和3对照，发现没有文件不同，故不推送数据，而发现5下没有分区15所相应的内容，故其须要将自己分区15所相应的文件推送给它，设备3也是相同的原理。

3 删除设备

集群又执行了一些时间。当中有些设备。由于执行时间较长。设备老化，现须要将其从集群删掉，Swift设备的删除，不是直接的物理删除，先将其weight设置为0，当其weight变为0后，其它的设备的part_wanted就好变大，故在rebalnace时须要先把设备1（加入删除设备1）所相应的分区都收回，然后再又一次分配给其它分区。

这个过程中replica2part2dev_ID变化例如以下：

  

                                                                        图6 删除设备后replica2part2dev_ID的变化

如图6所看到的（绿线上方为删除设备后的新映射，绿线和和蓝线之间为没有删除设备前加入设备后的分区映射。最底下为起初的映射）设备1所相应的全部分区都被收集了。而每个分区所相应的新的设备都会经过其它两个设备，来将他们文件下的对象推送给新映射的设备。

总结

以上是内存溢出为你收集整理的Openck_Swift源代码分析——添加、删除设备时算法详细的实现过程全部内容，希望文章能够帮你解决Openck_Swift源代码分析——添加、删除设备时算法详细的实现过程所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。