服務(wù)器上的網(wǎng)站是如何備份呢呢
我一般是總壓縮包
然后上傳到百度網(wǎng)盤
百度網(wǎng)盤容量真的夠用嗎
今天就探討一下百度云的實(shí)際容量是不是可以放下所有網(wǎng)站的備份
我想要為每個(gè)用戶提供 1G 的網(wǎng)絡(luò)存儲(chǔ)空間。
如果服務(wù)器上有一顆 1000G 的硬盤可以全部為用戶提供數(shù)據(jù)儲(chǔ)存,如果每個(gè)用戶分配 1G 的最大儲(chǔ)存空間,那么能非配給多少個(gè)用戶使用呢?
你一定說是 1000/1=1000 個(gè)用戶。
但事實(shí)上你這么分配了,你會(huì)發(fā)現(xiàn)每個(gè)用戶平時(shí)根本不會(huì)上傳 1G 的東西將容量占的漫漫的,有多又少,但平均用戶平時(shí)只上傳 50M 的文件,也就是說,你將 1000G 的硬盤分給 1000個(gè) 人使用,但只有效利用了其中的 50M*1000=50G 的空間,剩余 950G 的空間基本都完全浪費(fèi)了。
那么怎么解決呢?
你可以變通一下,將這 1000G 的空間分配給 20000個(gè) 用戶使用,每個(gè)人的上傳上限容量還是 1G,但每人平時(shí)還是平均上傳 50M 的數(shù)據(jù),那么 20000*50M=1000G,這下子就把寶貴的服務(wù)器上的存儲(chǔ)空間充分利用了。但你又怕這樣分配給 20000個(gè) 人后,萬一某一刻人們突然多上傳點(diǎn)數(shù)據(jù),那么用戶不是就覺察出來你分給人家的 1G 空間是假的了嗎?所以可以不分配那么多人,只分配給 19000 人,剩下一些空間做應(yīng)急之用。
突然發(fā)現(xiàn)一下子將可分配的用戶數(shù)量翻了 19倍啊,了不起。那還有買有辦法更加有效的利用一下呢?
如果我有 1000個(gè) 以上的服務(wù)器,一個(gè)服務(wù)器上有 1000G 空間,那么我們個(gè)服務(wù)器上都要留下 50G 的空白空間以備用戶突然上傳大數(shù)據(jù)時(shí)導(dǎo)致數(shù)據(jù)塞滿的情況,呢么我這 1000個(gè)服務(wù)器上就空出了 1000臺(tái)*50G=50000G 的空間被浪費(fèi)了,所么可惜。所以我們發(fā)明了計(jì)存儲(chǔ)集群,使得一個(gè)用戶的數(shù)據(jù)可以被分配在多個(gè)服務(wù)器上存儲(chǔ),但在用戶那看起來只是一個(gè) 1G 的連續(xù)空間,那么就沒必要在每個(gè)服務(wù)器上預(yù)留出應(yīng)急的空間了,甚至可以充分的將前一個(gè)服務(wù)器塞滿后,在將數(shù)據(jù)往下一個(gè)服務(wù)器中塞。這樣保證了服務(wù)器空間的最大利用,如果某一刻管理員發(fā)現(xiàn)用戶都在瘋狂上傳數(shù)據(jù)(在一個(gè)大規(guī)模用戶群下,這樣的概率少之又少)導(dǎo)致我現(xiàn)有提供的空間不夠了,沒關(guān)系,只需要隨手加幾塊硬盤或者服務(wù)器就解決了。
好吧,這下子我們的服務(wù)器空間利用高多了,可以將一定量的空間分配給最多的用戶使用了。但有沒有更好的改進(jìn)方案呢?
管理員有一天發(fā)現(xiàn),即使每個(gè)用戶平局下來只存儲(chǔ) 50M 的東西,但這 50M 也不是一蹴而就的,是隨著1-2年的使用慢慢的達(dá)到這個(gè)數(shù)量的,也就是說,一個(gè)新的用戶剛剛注冊(cè)我的網(wǎng)絡(luò)空間時(shí),不會(huì)上傳東西,或者只上傳一點(diǎn)非常小的東西。那么我為每一個(gè)用戶都初始分配了 50M 的空間,即使將來2年后他們會(huì)填滿這 50M ,但這期間的這空間就有很多時(shí)浪費(fèi)的啊。所以聰明的工程師說:既然我們可以分布式、集群式存儲(chǔ),一個(gè)用戶的數(shù)據(jù)可以分布在多個(gè)服務(wù)器上,那么我們就假設(shè)一開始就給一個(gè)新注冊(cè)的用戶提供 0M 的空間,將來他用多少,我就給他提供多少存儲(chǔ)空間,這樣就徹底的保證硬盤的利用了。但用戶的前端還是要顯示 1G 的。
工程師的這個(gè)點(diǎn)子,使得我在建立網(wǎng)盤初期能用 1臺(tái) 1000G 的服務(wù)器提供了大約 1000000 人來注冊(cè)和使用,隨著注冊(cè)的人多了,我也有錢了,也可以不斷增加服務(wù)器以提供他們后期的存貯了。同時(shí)因?yàn)橐徊糠址⻊?wù)器完了一年多購買,我的購買成本也下來了。
那么...這結(jié)束了嗎?若是郵箱提供商的話,這樣的利用率夠高了。但網(wǎng)盤就不一樣了。
聰明的工程師發(fā)現(xiàn):不同于郵箱,大家的內(nèi)容的附件絕大多數(shù)都是自創(chuàng)的和不同的。但網(wǎng)盤上大家上傳的東西很多都是重復(fù)的。
比如:張三 今天下載了一部《TOKYO HOT》上傳上傳到了自己的網(wǎng)盤上,李四在三天后也下載了一模一樣的《TOKYO HOT》上傳到了網(wǎng)絡(luò)硬盤上,隨著用戶的增多,你會(huì)發(fā)現(xiàn)總計(jì)有 1000個(gè)人 上傳了 1000份 一模一樣的文件到你寶貴的服務(wù)器空間上,所以工程師想出一個(gè)辦法,既然是一樣的文件,我就只存一份不久好啦,然后在用戶的前端顯示是沒人都有一份不久行啦。當(dāng)某些用戶要?jiǎng)h除這個(gè)文件的時(shí)候,我并不真的刪除,只需要在前端顯示似乎刪除了,但后端一直保留著以供其他擁有此文件的用戶下載。直到所有使用此文件的用戶都刪除了這個(gè)文件我再真的將其刪除吧。
這樣子隨著存儲(chǔ)的數(shù)據(jù)越來越多,注冊(cè)的用戶越來越多,其上傳的重復(fù)數(shù)據(jù)越來越多。你發(fā)現(xiàn)這樣的檢測(cè)重復(fù)文件存儲(chǔ)的效率越來越大。這樣算下來似乎每個(gè)人上傳的不重復(fù)的文件只能平均 1M/用戶。這下子你可以提供超過 50倍 的用戶使用您這有限的空間了。
但伴隨這使用,你又發(fā)現(xiàn)一個(gè)規(guī)律:
張三上傳的《TOKYO HOT N0124》和李四上傳的《TH n124》是同一個(gè)文件,只不過文件名不一樣,難道我就不能識(shí)別出他們是一個(gè)文件,然后只將其分別給不同的用戶保存成不同的文件名不久行啦?確實(shí)可行,但這要利用一些識(shí)別文件相同性的算法,例如 MD5 值等。只要兩個(gè)文件的 MD5 值一樣,文件大小一樣,我就認(rèn)為它們是相同的文件,只需要保存一份文件并給不同的用戶記作不同的文件名就好了。
有一天你發(fā)現(xiàn),因?yàn)槊恳粋(gè)文件都需要計(jì)算 MD5 值,導(dǎo)致 CPU 負(fù)荷很大,而且本來一樣的文件非要浪費(fèi)帶寬上傳回來才可以檢測(cè)一致性,能改進(jìn)一下嗎?
聰明的工程師寫了個(gè)小軟件/.小插件,美其名曰“上傳控件”,將計(jì)算 MD5 的工作利用這個(gè)軟件交給了上傳用戶的點(diǎn)老來完成,一旦計(jì)算出用戶要上傳的數(shù)據(jù)和服務(wù)器上已經(jīng)存儲(chǔ)的某個(gè)數(shù)據(jù)是一樣的,就干脆不用上傳了,直接在用戶那里標(biāo)記上這個(gè)文件已經(jīng)按照 XX 文件名上傳成功了。這個(gè)過程幾乎是瞬間搞定了,并給其起了個(gè)高富帥的名字“秒傳”!
通過以上這么多步驟,你發(fā)現(xiàn)本來你只能給 1000用戶 提供網(wǎng)絡(luò)空間的,這么多改進(jìn)辦法后,在用戶端顯示 1G 空間不變的情況下,近乎可以為 1000000個(gè)用戶 提供網(wǎng)絡(luò)空間了。
這樣若是您哪天心情好,對(duì)外宣傳說:我要將每個(gè)用戶的存儲(chǔ)空間上限提升到 1TB。那么每個(gè)用戶平均還是只上傳 50M 數(shù)據(jù),只有極個(gè)別極個(gè)別的用戶上傳了突破 1G 原始空間的數(shù)據(jù),你會(huì)發(fā)現(xiàn)所付出的成本近乎是微乎其微的。
辛勤的工程師還在為如何更有效率的利用服務(wù)器提供的磁盤空間在不屑努力和挖掘著......