云存储备份方案研究（完整版）

　　实验室之前做过一个云存储的项目，我进来的时候刚好结项啦。

　　生不逢时啊有木有，为什么我一进来项目就做完了？我可是对这个很有兴趣啊！

　　项目是基于B/S架构的啦，前端用flex做的实现，后端用JAVA写的实现。服务器用的Apache。

　　整个云存储的项目是参考谷歌的云平台做的，把谷歌的云存储策略能用的基本都搬过来啦。

　　可是啊，不知道基于什么考虑，谷歌没有公布自己的存储备份策略哦。这也是本文关注的重点。

　　项目的拓扑结构如图所示。

　　用户上传文件信息到主服务器，主服务器根据文件信息按一定大小对文件进行分片（逻辑上的），再将分片结果发送给用户。

　　用户收到分片结果后直接将不同的文件块发送到不同的存储服务器上。

　　这些都是参照谷歌的云存储策略来做的。

　　接下来就是备份的问题了。

　　我们知道硬件在老化之后很容易出现故障，那么一个强健的云存储备份系统，在系统出现小规模的故障之后，应该能保证：

　　1、文件的安全

　　2、快速恢复

　　项目的做法是：

　　1、将文件划分成许多个5mb大小的文件块（block:0,1,2,3,4....Bn）。

　　2、为存储节点编号（computer:0,1,2,3,4,5,6......Cn）。

　　3、blockNumber  % Cn 就是这个block所存储的位置。

　　4、每个块会准备两个副本，那么到了第n(n=1 or 2)个副本的存储时，（blockNumber % Cn）+n就是这个副本block所存储的位置。

　　比如说下面的简单例子：

　　假设有三个存储节点，分别标识为：c0,c1,c2；

　　一个50m大小的文件，被分块为：f0,f1,f2,f3,f4,f5,f6,f7,f8,f9.

　　第一次存储时的情况：

　　c0存储的块为：0,3,6,9

　　c1存储的快为：1,4,7

　　c2存储的快为：2,5,8

　　第一个副本存储时的情况：

　　c0存储的块为：0,3,6,9,2,5,8

　　c1存储的快为：1,4,7,0,3,6,9

　　c2存储的快为：2,5,8,1,4,7

　　第二个副本存储时的情况：

　　c0存储的块为：0,3,6,9,2,5,8,1,4,7

　　c1存储的快为：1,4,7,0,3,6,9,2,5,8

　　c2存储的快为：2,5,8,1,4,7,0,3,6,9

　　这里做到了，任意两台机器坏掉了，仍然会有一个机器存有完整的文件片段。

　　当然，这里的例子比较简单，还没有完全体现这种方法的强大之处，下面我会用一个复杂点的例子来说明这个备份策略。

　　假设有四个存储节点，分别标识为：c0,c1,c2,c3；

　　存储的块有6个：b0,b1,b2,b3,b4,b5

　　存储结果为：

　　c0存储的块为：0 4 3 2

　　c1存储的快为：1 5 0 4 3

　　c2存储的快为：2 1 5 0 4

　　c3存储的快为：3 2 1 5

　　按照这种存储方法得到的结果是，任意两台存储节点坏了，剩下了两台机器都能恢复完整的文件。

　　实际应用情况下，存储节点是1个接1个坏掉的，很少出现超过2个机器同时坏掉的。当然，更安全的做法是在一个遥远的地方布置数据中心按此方法对数据进行备份。

　　当一个存储节点坏掉时，主节点能够在很短的时间内发现，原因是系统采取的心跳机制。

　　一旦主节点发现了损坏的存储节点时，马上会选取一个未使用节点替代这个节点。其他节点会为这个替代节点传输损坏节点的数据。