想到這個問題時，我真正感到疑惑的是百度云上是否真的存在用戶數(shù)*用戶空間大小的硬盤空間，那這樣的成本又會是多少？
在某乎上找到了一篇通俗易懂的文章，下面分享給大家，相互學(xué)習(xí)！
文章來源：
http://www.zhihu.com/question/21591490

我想要為每個用戶提供 1G 的網(wǎng)絡(luò)存儲空間。

如果服務(wù)器上有一顆 1000G 的硬盤可以全部為用戶提供數(shù)據(jù)儲存，如果每個用戶分配 1G 的最大儲存空間，那么能非配給多少個用戶使用呢？

你一定說是 1000/1=1000 個用戶。

但事實上你這么分配了，你會發(fā)現(xiàn)每個用戶平時根本不會上傳 1G 的東西將容量占的漫漫的，有多又少，但平均用戶平時只上傳 50M 的文件，也就是說，你將 1000G 的硬盤分給 1000個 人使用，但只有效利用了其中的 50M*1000=50G 的空間，剩余 950G 的空間基本都完全浪費了。

那么怎么解決呢？

你可以變通一下，將這 1000G 的空間分配給 20000個 用戶使用，每個人的上傳上限容量還是 1G，但每人平時還是平均上傳 50M 的數(shù)據(jù)，那么 20000*50M=1000G，這下子就把寶貴的服務(wù)器上的存儲空間充分利用了。但你又怕這樣分配給 20000個 人后，萬一某一刻人們突然多上傳點數(shù)據(jù)，那么用戶不是就覺察出來你分給人家的 1G 空間是假的了嗎？所以可以不分配那么多人，只分配給 19000 人，剩下一些空間做應(yīng)急之用。

突然發(fā)現(xiàn)一下子將可分配的用戶數(shù)量翻了 19倍啊，了不起。那還有買有辦法更加有效的利用一下呢？

如果我有 1000個 以上的服務(wù)器，一個服務(wù)器上有 1000G 空間，那么我們個服務(wù)器上都要留下 50G 的空白空間以備用戶突然上傳大數(shù)據(jù)時導(dǎo)致數(shù)據(jù)塞滿的情況，呢么我這 1000個服務(wù)器上就空出了 1000臺*50G=50000G 的空間被浪費了，所么可惜。所以我們發(fā)明了計存儲集群，使得一個用戶的數(shù)據(jù)可以被分配在多個服務(wù)器上存儲，但在用戶那看起來只是一個 1G 的連續(xù)空間，那么就沒必要在每個服務(wù)器上預(yù)留出應(yīng)急的空間了，甚至可以充分的將前一個服務(wù)器塞滿后，在將數(shù)據(jù)往下一個服務(wù)器中塞。這樣保證了服務(wù)器空間的最大利用，如果某一刻管理員發(fā)現(xiàn)用戶都在瘋狂上傳數(shù)據(jù)（在一個大規(guī)模用戶群下，這樣的概率少之又少）導(dǎo)致我現(xiàn)有提供的空間不夠了，沒關(guān)系，只需要隨手加幾塊硬盤或者服務(wù)器就解決了。

好吧，這下子我們的服務(wù)器空間利用高多了，可以將一定量的空間分配給最多的用戶使用了。但有沒有更好的改進方案呢？

管理員有一天發(fā)現(xiàn)，即使每個用戶平局下來只存儲 50M 的東西，但這 50M 也不是一蹴而就的，是隨著1-2年的使用慢慢的達到這個數(shù)量的，也就是說，一個新的用戶剛剛注冊我的網(wǎng)絡(luò)空間時，不會上傳東西，或者只上傳一點非常小的東西。那么我為每一個用戶都初始分配了 50M 的空間，即使將來2年后他們會填滿這 50M ，但這期間的這空間就有很多時浪費的啊。所以聰明的工程師說：既然我們可以分布式、集群式存儲，一個用戶的數(shù)據(jù)可以分布在多個服務(wù)器上，那么我們就假設(shè)一開始就給一個新注冊的用戶提供 0M 的空間，將來他用多少，我就給他提供多少存儲空間，這樣就徹底的保證硬盤的利用了。但用戶的前端還是要顯示 1G 的。

工程師的這個點子，使得我在建立網(wǎng)盤初期能用 1臺 1000G 的服務(wù)器提供了大約 1000000 人來注冊和使用，隨著注冊的人多了，我也有錢了，也可以不斷增加服務(wù)器以提供他們后期的存貯了。同時因為一部分服務(wù)器完了一年多購買，我的購買成本也下來了。

那么…這結(jié)束了嗎？若是郵箱提供商的話，這樣的利用率夠高了。但網(wǎng)盤就不一樣了。

聰明的工程師發(fā)現(xiàn)：不同于郵箱，大家的內(nèi)容的附件絕大多數(shù)都是自創(chuàng)的和不同的。但網(wǎng)盤上大家上傳的東西很多都是重復(fù)的。

比如：張三 今天下載了一部《TOKYO HOT》上傳上傳到了自己的網(wǎng)盤上，李四在三天后也下載了一模一樣的《TOKYO HOT》上傳到了網(wǎng)絡(luò)硬盤上，隨著用戶的增多，你會發(fā)現(xiàn)總計有 1000個人 上傳了 1000份 一模一樣的文件到你寶貴的服務(wù)器空間上，所以工程師想出一個辦法，既然是一樣的文件，我就只存一份不久好啦，然后在用戶的前端顯示是沒人都有一份不久行啦。當(dāng)某些用戶要刪除這個文件的時候，我并不真的刪除，只需要在前端顯示似乎刪除了，但后端一直保留著以供其他擁有此文件的用戶下載。直到所有使用此文件的用戶都刪除了這個文件我再真的將其刪除吧。

這樣子隨著存儲的數(shù)據(jù)越來越多，注冊的用戶越來越多，其上傳的重復(fù)數(shù)據(jù)越來越多。你發(fā)現(xiàn)這樣的檢測重復(fù)文件存儲的效率越來越大。這樣算下來似乎每個人上傳的不重復(fù)的文件只能平均 1M/用戶。這下子你可以提供超過 50倍 的用戶使用您這有限的空間了。

但伴隨這使用，你又發(fā)現(xiàn)一個規(guī)律：

張三上傳的《TOKYO HOT N0124》和李四上傳的《TH n124》是同一個文件，只不過文件名不一樣，難道我就不能識別出他們是一個文件，然后只將其分別給不同的用戶保存成不同的文件名不久行啦？確實可行，但這要利用一些識別文件相同性的算法，例如 MD5 值等。只要兩個文件的 MD5 值一樣，文件大小一樣，我就認為它們是相同的文件，只需要保存一份文件并給不同的用戶記作不同的文件名就好了。

有一天你發(fā)現(xiàn)，因為每一個文件都需要計算 MD5 值，導(dǎo)致 CPU 負荷很大，而且本來一樣的文件非要浪費帶寬上傳回來才可以檢測一致性，能改進一下嗎？

聰明的工程師寫了個小軟件/.小插件，美其名曰“上傳控件”，將計算 MD5 的工作利用這個軟件交給了上傳用戶的點老來完成，一旦計算出用戶要上傳的數(shù)據(jù)和服務(wù)器上已經(jīng)存儲的某個數(shù)據(jù)是一樣的，就干脆不用上傳了，直接在用戶那里標記上這個文件已經(jīng)按照 XX 文件名上傳成功了。這個過程幾乎是瞬間搞定了，并給其起了個高富帥的名字“秒傳”！

通過以上這么多步驟，你發(fā)現(xiàn)本來你只能給 1000用戶 提供網(wǎng)絡(luò)空間的，這么多改進辦法后，在用戶端顯示 1G 空間不變的情況下，近乎可以為 1000000個用戶 提供網(wǎng)絡(luò)空間了。

這樣若是您哪天心情好，對外宣傳說：我要將每個用戶的存儲空間上限提升到 1TB。那么每個用戶平均還是只上傳 50M 數(shù)據(jù)，只有極個別極個別的用戶上傳了突破 1G 原始空間的數(shù)據(jù)，你會發(fā)現(xiàn)所付出的成本近乎是微乎其微的。

辛勤的工程師還在為如何更有效率的利用服務(wù)器提供的磁盤空間在不屑努力和挖掘著……

總結(jié)

以上是生活随笔為你收集整理的为什么百度云可以给每位用户分配两T的存储空间？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。