Web2.0網(wǎng)站，數(shù)據(jù)內(nèi)容以幾何級(jí)數(shù)增長(zhǎng)，尤其是那些小文件，幾K～幾百K不等，數(shù)量巨多，傳統(tǒng)的文件系統(tǒng)處理起來(lái)很是吃力，很多網(wǎng)站在scaling的過(guò)程中都遇到了這樣的問(wèn)題：磁盤(pán)IO過(guò)高；備份困難；單點(diǎn)問(wèn)題，容量和讀寫(xiě)無(wú)法水平擴(kuò)展，還存在故障的可能。

YouTube也碰到這樣的問(wèn)題，每一個(gè)視頻有4個(gè)縮微圖，這樣的話(huà)縮微圖數(shù)量是視頻數(shù)量的四倍，想象一下YouTube有多少視頻，看一下他們遇到的問(wèn)題：

• 大量的磁盤(pán)尋址，在操作系統(tǒng)層面出現(xiàn)inodes cache和page cache的問(wèn)題
• 單個(gè)目錄文件數(shù)限制，尤其是Ext3文件系統(tǒng)，采用目錄分級(jí)的做法，最新的Linux Kernel 2.6優(yōu)化了Ext3文件系統(tǒng)，單目錄能存儲(chǔ)的文件數(shù)提高了100倍，但是把所有的文件存一個(gè)目錄不是一個(gè)好的方法
• 高RPS（requests per second每秒請(qǐng)求數(shù)），因?yàn)橐粋€(gè)頁(yè)面可能要顯示60個(gè)縮微圖
• 高負(fù)載下Apache性能差
• Apache前面加一層Squid，能抗一會(huì)，但負(fù)載上來(lái)之后，性能下降厲害，由300RPS降到20RPS
• 嘗試lighttpd，但是lighttpd是單線(xiàn)程，多線(xiàn)程的話(huà)也有問(wèn)題，線(xiàn)程之間緩存不能共享
• 加一臺(tái)服務(wù)器的話(huà)需要24小時(shí)，因?yàn)槲募?shù)太多了
• 存在“冷卻”的問(wèn)題，重啟服務(wù)器后需要6～10個(gè)小時(shí)才能緩存好

YouTube的解決方案是Google的BigTable，一般人沒(méi)戲。（原文參見(jiàn)： http://www.hfadeel.com/Blog/?p=127 ）

Facebook也遇到了同樣的問(wèn)題，他們的方案參見(jiàn)： http://www.dbanotes.net/arch/facebook_photos_arch.html ，他們經(jīng)歷了三個(gè)階段：

1. NFS共享，掛一個(gè)盤(pán)陣，APP服務(wù)器通過(guò)NFS讀寫(xiě)
2. 加一個(gè)中間層Cachr：eventHttp + memcached(lighttpd + mod_memcache實(shí)現(xiàn)同樣的功能)，后端還是通過(guò)NFS連盤(pán)陣
3. Haystacks，詳細(xì)的去讀 這里 （E文）。

對(duì)于一般的網(wǎng)站來(lái)說(shuō)，實(shí)用的方案有哪些呢？

一、NFS共享

是的，這個(gè)有很多問(wèn)題，但實(shí)施成本低，很多公司都在用（我們也在用），在不是那么多文件，不是那么高并發(fā)的情況下還是很不錯(cuò)的，設(shè)置Hash目錄，不要讓一個(gè)目錄下文件數(shù)過(guò)多，對(duì)于一般的網(wǎng)站來(lái)說(shuō)足夠用了。

備份確實(shí)是一個(gè)問(wèn)題，如果不是海量的話(huà)，根據(jù)文件更新時(shí)間每天增量備份＋周期性的全量備份應(yīng)該可以。

二、文件存數(shù)據(jù)庫(kù)

真有人這么做， 手機(jī)之家 用MySQL建了256個(gè)表來(lái)存儲(chǔ)超過(guò)1T的文件，前端加一個(gè)多級(jí)緩存（具體未知，也許就是memcached也許還是文件），數(shù)據(jù)庫(kù)做數(shù)據(jù)備份用，他們用起來(lái)覺(jué)得還不錯(cuò)。

或者覺(jué)得MySQL太重，試試key->value的數(shù)據(jù)庫(kù)，比如BDB，Tokyo Cabinet等。

三、分布式文件系統(tǒng)

開(kāi)源的很多， 好看簿 用的是 MogileFS ，與memcached師出同門(mén)。 傲游 用 MFS 來(lái)存儲(chǔ)用戶(hù)的收藏夾文件，詳細(xì)文章參見(jiàn)： 分布式文件系統(tǒng)MFS(moosefs)實(shí)現(xiàn)存儲(chǔ)共享(一) 、 (二) ，據(jù)說(shuō)數(shù)百萬(wàn)輕松處理。

分布式文件系統(tǒng)好處是可以均衡讀寫(xiě)壓力，數(shù)據(jù)可靠性大大增加，某個(gè)數(shù)據(jù)節(jié)點(diǎn)掛了也沒(méi)事。

還不行？自己DIY一個(gè)去吧，豆瓣就這么做的，TokyoCabinet做為底層存儲(chǔ)，封裝了一個(gè)memcached協(xié)議接口（與 Tokyo Tyrant 何異？），一致性哈希，應(yīng)用程序根據(jù)哈希規(guī)則在node中讀寫(xiě)數(shù)據(jù):

DoubanFS結(jié)構(gòu)圖

海量小文件存儲(chǔ)