百度網盤是如何能夠做到給每個人2TB空間的!

2018年年底,百度雲盤宣佈,未來一年未登陸過百度雲盤的用戶,網盤容量將會縮減到100G。由此可看出百度網盤針對一些不活躍用戶進行存儲容量限制,以節約資源。

對於想保存自己2TB內存大小的用戶,今年隨便登陸下百度網盤就可以,想薅(破)羊(解)毛(限)的(速)可以查看我上一篇文章。

百度網盤是如何能夠做到給每個人2TB空間的!

今天給大家科普下,當初百度網盤是如何可以給用戶2TB容量的網盤內存的!

假如我想要為每個用戶提供1G的網絡存儲空間。如果服務器上有一顆100G的硬盤可以全部為用戶提供數據儲存,如果每個用戶分配1G的最大儲存空間,那麼能分配給多少個用戶使用呢?你一定說是100/1=100個用戶。

但是事實上你這麼分配了,你會發現每個用戶平時根本不會上傳1G的東西將容量佔的滿滿的,有多有少,但平均用戶平時只上傳50M的文件,也就是說,如果你將1000G的硬盤分給1000個人使用,但只有效利用了其中的50M*1000=50G的空間,剩餘950G的空間基本都完全浪費了。

百度網盤是如何能夠做到給每個人2TB空間的!

隨便截的圖

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

突然發現一下子將可分配的用戶數量翻了19倍啊,了不起。

百度網盤是如何能夠做到給每個人2TB空間的!

嗯,插個表情包

那還有沒有辦法更加有效的利用一下呢?

如果我有1000個以上的服務器,一個服務器上有1000G空間,那麼我們每個服務器上都要留下50G的空白空間以備用戶突然上傳大數據時導致數據塞滿的情況,那麼我這1000個服務器上就空出了1000臺*50G=50000G的空間被浪費了,多麼可惜。

所以程序員發明了存儲集群技術,使得一個用戶的數據可以被分配在多個服務器上存儲,但在用戶那看起來只是一個1G的連續空間,那麼就沒必要在每個服務器上預留出應急的空間了,甚至可以充分的將前一個服務器塞滿後,在將數據往下一個服務器中塞。

百度網盤是如何能夠做到給每個人2TB空間的!

這個圖應該可以理解吧,我是看不懂英文..

這樣保證了服務器空間的最大利用,如果某一刻管理員發現用戶都在瘋狂上傳數據(在一個大規模用戶群下,這樣的概率少之又少)導致我現有提供的空間不夠了,沒關係,只需要隨手加幾塊硬盤或者服務器就解決了。

好吧,這下子我們的服務器空間利用高多了,可以將一定量的空間分配給最多的用戶使用了。但有沒有更好的改進方案呢?管理員有一天發現,即使每個用戶平均下來只存儲50M的東西,但這50M也不是一蹴而就的,是隨著1-2年的使用慢慢的達到這個數量的,也就是說,一個新的用戶剛剛註冊我的網絡空間時,不會上傳東西,或者只上傳一點非常小的東西。

百度網盤是如何能夠做到給每個人2TB空間的!

圖片不夠,表情來湊~

那麼我為每一個用戶都初始分配了50M的空間,即使將來2年後他們會填滿這50M,但這期間的這空間就有很多是浪費的啊。

但是既然我們可以分佈式、集群式存儲,一個用戶的數據可以分佈在多個服務器上,那麼我們就假設一開始就給一個新註冊的用戶提供0M的空間,將來他用多少,我就給他提供多少存儲空間,這樣就徹底的保證硬盤的利用了。

但用戶的前端還是要顯示1G的。工程師的這個點子,使得我在建立網盤初期能用1臺1000G的服務器提供了大約1000000人來註冊和使用,隨著註冊的人多了,我也有錢了,也可以不斷增加服務器以提供他們後期的存儲了。

百度網盤是如何能夠做到給每個人2TB空間的!

同時因為一部分服務器完成了一年多購買,我的購買成本也下來了。那麼…這就結束了嗎?若是郵箱提供商的話,這樣的利用率夠高了。

但網盤就不一樣了。有工程師發現:不同於郵箱,大家的內容和附件絕大多數都是自創的和不同的。

但網盤上大家上傳的東西很多都是重複的。比如:張三今天從網盤下載了一個《百草街》上傳到了自己的網盤上,李四在三天後也下載了一模一樣的《百草街》上傳到了網絡硬盤上,隨著用戶的增多,你會發現總共有1000個人上傳了1000份一模一樣的文件到你的服務器空間上,所以工程師想出一個辦法,既然是一樣的文件,我就只存一份不就行了?然後在用戶的前端顯示是沒人都有一份不就行了。

百度網盤是如何能夠做到給每個人2TB空間的!

當某些用戶要刪除這個文件的時候,我並不真的刪除,只需要在前端顯示似乎刪除了,但後端一直保留著以供其他擁有此文件的用戶下載。直到所有使用此文件的用戶都刪除了這個文件我再真的將其刪除吧。這樣子隨著存儲的數據越來越多,註冊的用戶越來越多,其上傳的重複數據越來越多。你發現這樣的檢測重複文件存儲的效率越來越大。這樣算下來似乎每個人上傳的不重複的文件只能平均1M/用戶。這下子你可以提供超過50倍的用戶使用你這有限的空間了。

但伴隨著使用,你發現一個規律:張三上傳的《百草街》和李四上傳的《百消丹》是同一個文件,只不過文件名不一樣,難道我就不能識別出他們是一個文件,然後只將其分別給不同的用戶保存成不同的文件名不就行了?

百度網盤是如何能夠做到給每個人2TB空間的!

確實可行,但這要利用一些識別文件相同性的算法,例如MD5值等。只要兩個文件的MD5值一樣,文件大小一樣,我就認為它們是相同的文件,只需要保存一份文件並給不同的用戶記作不同的文件名就好了。有一天你發現,因為每一個文件都需要計算MD5值,導致CPU負荷很大,而且本來一樣的文件非要浪費帶寬上傳回來才可以檢測一致性,能改進一下嗎?

開發工程師可以寫個小軟件或小插件,美其名曰“上傳控件”,將計算MD5的工作利用這個軟件交給了上傳用戶的電腦來完成,一旦計算出用戶要上傳的數據和服務器上已經存儲的某個數據是一樣的,就乾脆不用上傳了,直接在用戶那裡標記上這個文件已經按照XX文件名上傳成功了。

百度網盤是如何能夠做到給每個人2TB空間的!

這個過程幾乎是瞬間搞定了,並給其起了個高富帥的名字“秒傳”!通過以上這麼多步驟,你發現本來你只能給1000用戶提供網絡空間的,這麼多改進辦法後,在用戶端顯示1G空間不變的情況下,近乎可以為1000000個用戶提供網絡空間了。

這樣若是哪天心情好,對外宣傳說:我要將每個用戶的存儲空間上限提升到1TB。那麼每個用戶平均還是隻上傳50M數據,只有極個別的用戶上傳了突破1G原始空間的數據,你會發現所付出的成本近乎是微乎其微的。辛勤的開發工程師還在為如何更有效率的利用服務器提供的磁盤空間在不屑努力和挖掘著。

百度網盤是如何能夠做到給每個人2TB空間的!

講了這麼多,不知道大家懂不懂呢。

下期講講百度網盤是咋這麼多用戶的,講講他的營銷套路。


分享到:


相關文章: