科普帖子：那些网盘的秒传，怎么实现的？有何优劣？

共计 4115 个字符，预计需要花费 11 分钟才能阅读完成。

故事篇：

前国内各家大公司之间的网盘大战吵的沸沸扬扬，很多同学都在自己的博客上说今天领取了XXXT容量，1元XXXX，免费升级到XXT之类的，鸡冻你没发现dropbox这种网盘鼻祖却始终提供那么点容量，你们就没有想到过为什么么？我只想说，图样图森破啊~

事实是这样的~

我想要为每个用户提供 1G 的网络存储空间。

如果服务器上有一颗 1000G 的硬盘可以全部为用户提供数据储存，如果每个用户分配 1G 的最大储存空间，那么能非配给多少个用户使用呢？

你一定说是 1000/1=1000 个用户。

但 事实上你这么分配了，你会发现每个用户平时根本不会上传 1G 的东西将容量占的漫漫的，有多又少，但平均用户平时只上传 50M 的文件，也就是说，你将 1000G 的硬盘分给 1000个 人使用，但只有效利用了其中的 50M*1000=50G 的空间，剩余 950G 的空间基本都完全浪费了。

那么怎么解决呢？

你可以变通一下，将这 1000G 的空间分配给 20000个 用户使用，每个人的上传上限容量还是 1G，但每人平时还是平均上传 50M 的数据，那么 20000*50M=1000G，这下子就把宝贵的服务器上的存储空间充分利用了。但你又怕这样分配给 20000个 人后，万一某一刻人们突然多上传点数据，那么用户不是就觉察出来你分给人家的 1G 空间是假的了吗？所以可以不分配那么多人，只分配给 19000 人，剩下一些空间做应急之用。

突然发现一下子将可分配的用户数量翻了 19倍啊，了不起。那还有买有办法更加有效的利用一下呢？

如 果我有 1000个 以上的服务器，一个服务器上有 1000G 空间，那么我们个服务器上都要留下 50G 的空白空间以备用户突然上传大数据时导致数据塞满的情况，呢么我这 1000个服务器上就空出了 1000台*50G=50000G 的空间被浪费了，所么可惜。所以我们发明了计存储集群，使得一个用户的数据可以被分配在多个服务器上存储，但在用户那看起来只是一个 1G 的连续空间，那么就没必要在每个服务器上预留出应急的空间了，甚至可以充分的将前一个服务器塞满后，在将数据往下一个服务器中塞。这样保证了服务器空间的 最大利用，如果某一刻管理员发现用户都在疯狂上传数据（在一个大规模用户群下，这样的概率少之又少）导致我现有提供的空间不够了，没关系，只需要随手加几 块硬盘或者服务器就解决了。

好吧，这下子我们的服务器空间利用高多了，可以将一定量的空间分配给最多的用户使用了。但有没有更好的改进方案呢？

管 理员有一天发现，即使每个用户平局下来只存储 50M 的东西，但这 50M 也不是一蹴而就的，是随着1-2年的使用慢慢的达到这个数量的，也就是说，一个新的用户刚刚注册我的网络空间时，不会上传东西，或者只上传一点非常小的东 西。那么我为每一个用户都初始分配了 50M 的空间，即使将来2年后他们会填满这 50M ，但这期间的这空间就有很多时浪费的啊。所以聪明的工程师说：既然我们可以分布式、集群式存储，一个用户的数据可以分布在多个服务器上，那么我们就假设一 开始就给一个新注册的用户提供 0M 的空间，将来他用多少，我就给他提供多少存储空间，这样就彻底的保证硬盘的利用了。但用户的前端还是要显示 1G 的。

工程师的这个点子，使得我在建立网盘初期能用 1台 1000G 的服务器提供了大约 1000000 人来注册和使用，随着注册的人多了，我也有钱了，也可以不断增加服务器以提供他们后期的存贮了。同时因为一部分服务器完了一年多购买，我的购买成本也下来了。

那么…这结束了吗？

若是邮箱提供商的话，这样的利用率够高了。但网盘就不一样了。

聪明的工程师发现：不同于邮箱，大家的内容的附件绝大多数都是自创的和不同的。但网盘上大家上传的东西很多都是重复的。

比 如：张三 今天下载了一部《TOKYO HOT》上传上传到了自己的网盘上，李四在三天后也下载了一模一样的《TOKYO HOT》上传到了网络硬盘上，随着用户的增多，你会发现总计有 1000个人 上传了 1000份 一模一样的文件到你宝贵的服务器空间上，所以工程师想出一个办法，既然是一样的文件，我就只存一份不久好啦，然后在用户的前端显示是没人都有一份不久行 啦。当某些用户要删除这个文件的时候，我并不真的删除，只需要在前端显示似乎删除了，但后端一直保留着以供其他拥有此文件的用户下载。直到所有使用此文件 的用户都删除了这个文件我再真的将其删除吧。

这样子随着存储的数据越来越多，注册的用户越来越多，其上传的重复数据越来越多。你发现这样的检测重复文件存储的效率越来越大。这样算下来似乎每个人上传的不重复的文件只能平均 1M/用户。这下子你可以提供超过 50倍 的用户使用您这有限的空间了。

但伴随这使用，你又发现一个规律：

张 三上传的《TOKYO HOT N0124》和李四上传的《TH n124》是同一个文件，只不过文件名不一样，难道我就不能识别出他们是一个文件，然后只将其分别给不同的用户保存成不同的文件名不久行啦？确实可行，但 这要利用一些识别文件相同性的算法，例如 MD5 值等。只要两个文件的 MD5 值一样，文件大小一样，我就认为它们是相同的文件，只需要保存一份文件并给不同的用户记作不同的文件名就好了。

有一天你发现，因为每一个文件都需要计算 MD5 值，导致 CPU 负荷很大，而且本来一样的文件非要浪费带宽上传回来才可以检测一致性，能改进一下吗？

聪 明的工程师写了个小软件/.小插件，美其名曰“上传控件”，将计算 MD5 的工作利用这个软件交给了上传用户的点老来完成，一旦计算出用户要上传的数据和服务器上已经存储的某个数据是一样的，就干脆不用上传了，直接在用户那里标 记上这个文件已经按照 XX 文件名上传成功了。这个过程几乎是瞬间搞定了，并给其起了个高富帅的名字“秒传”！

通过以上这么多步骤，你发现本来你只能给 1000用户 提供网络空间的，这么多改进办法后，在用户端显示 1G 空间不变的情况下，近乎可以为 1000000个用户 提供网络空间了。

这样若是您哪天心情好，对外宣传说：我要将每个用户的存储空间上限提升到 1TB。那么每个用户平均还是只上传 50M 数据，只有极个别极个别的用户上传了突破 1G 原始空间的数据，你会发现所付出的成本近乎是微乎其微的。

解析篇：

前阵子，百度网盘提 供免费申请100G空间，当时一则出于好奇，二则自己移动硬盘由于使用了BT，悲催的经常出现报错，就想借此机会将文件传到百度上暂存下，腾出空间好好整 理下移动硬盘，就也弄了一个帐号。100G，加上原来的5G，一共105GB到手，正好今天有时间，就准备将移动硬盘数据拷贝上去了。打开百度云-网盘之 后，出现下面图：

_{注：此图片来源网上，本地的截图由于已经使用了极速控件，没法操作。}

下载安装之后，就是个IE插件，然后我们来体验下吧，体验截图如下：

前三个文件，状态开始是文件比对…，而后，立马上传成功，果然秒传啊，心想要按这个速度，上传所有的文件基本上就是分分钟的事情啊，结果，在第 四个文件的时候，它开始慢悠悠的给我上传了，速度稳定在60Kb左右，汗！这速度，要传完所有的文件，那是得猴年马月？这也算极速秒传。石化片刻之后，我 终于明白它这极速秒传是怎么个一回事了。在让我下载的插件无非就是个HASH工具，然后将我本地文件和服务器已有文件进行比对，如果有，就直接使用服务器文件 —— 这就是秒传！ 没有的文件，就慢悠悠的给你上传。

好吧，如果按照他这个秒传的概念，我们也非常容易的实现秒传功能，就一个文件HASH嘛。那趁着现在还在上传这档口，来自己设计一个简单的秒传架构吧。

原理篇：

要实现秒传，最核心的就是建立服务端与客户端的文件比对功能，这个比对当下可以用的有MD5这样的算法或者其他HASH算法。其步骤如下：

1. 让用户下载客户端，这个可以是浏览器插件，也可以是客户端软件 —— 百度这里是IE插件；

2. 在文件上传之初，将本地文件进行HASH计算，得出文件指纹；

3. 将文件指纹数据上传到服务器；

4. 服务端将文件指纹和现存的文件指纹进行比对，并返回比对结果给客户端；

5.客户端获取比对结果；

6. 如果是比对成功，则说明服务端已经有同样的文件存在，则直接将文件名和指纹及文件标识符一并上传到服务端，而服务端在接受到之后，只是将文件名存放在客户的名下，文件则是映射到原有文件的路径中，返回秒传成功信息；

7. 如果比对不成功，就变得和普通上传并无二致，老老实实的通过HTTP的方式，将文件1比特，1比特的上传到服务端。

好吧，这就是玄乎的文件秒传了。至于为什么要4GB的限制，这个个人初步认为是因为指纹计算也是需要消耗资源，如果文件过大，在计算指纹的时候，其占用资源也会相对较多，可能会造成一定的影响。真相具体为什么，还有请懂行的指点。

优势：

1. 对于服务端：进行文件的服务端比对，而后进行文件映射的这种方式，对于大型的存储来说，由于在服务端只存在一份文件实体，因此，对于系统的存储消耗将能极大的降低。特别是在文件数量达到海量，并且有很多重复文件时（多用户各自保存文件时），其效果更佳。

2. 对于传输的带宽：对于用户来说，由于服务端的海量文件，自己传输的如果是其中已存在的文件时，能够极大的降低带宽的占用情况。

劣势：

由于要实现秒传，并达到最优的效果，核心是要求服务端保存海量文件，而且及时所有用户将文件删除，服务端为了在下次实现秒传，都必须将文件保存在服务端，而不能进行删除。如果未被映射的文件数量巨大，这势必会增加存储成本。

隐患：

也许秒传给客户带来了便利，让我们感觉良好。但我们从秒传的原理中也不难发现其中的安全隐患。 由于文件必须在服务端保留，因此，如果你传输到服务端的文件包含隐私，那么，一旦上传完成，你的隐私就永远的存在于服务端了，这就很难保证你的这些隐私在 将来不会泄漏。如果真要使用这么一些个服务的时候，我们需要仔细的分析其中的风险。并且做出必要的决断。 —— 至少，在我看到这个功能之后，我当即就决定，只将自己的一些电影文件和其他不涉及隐私文件上传到服务端，而涉及到隐私的，或稍微敏感些的其他文件，我将用 其他办法来处理。

没有软件能够保护隐私安全，为了自身的利益，他们只会在最大的可能范围能截取客户隐私，要保护这些敏感信息，只能靠你自己！