現(xiàn)在的網(wǎng)站越做越大了，存儲的東西越來越多，如何解決這些文件存儲也成了新的難題。如果把這些文件都完全采用大硬盤存儲來解決，并不是一個好主意，因為數(shù)據(jù)量越大風險就越高，雖然文件能存得下，但是故障率相應會較高，另外重建耗費時間也比較長。所以最好的辦法是盡可能考慮分布式存儲，把文件想辦法利用網(wǎng)絡分散到多個機器上。

從我所了解的存儲結構來看，分布式存儲大致可以分為幾種：

1、類googlefs的分布式文件系統(tǒng)

因為目前googlefs沒有開源，所以網(wǎng)上出現(xiàn)的分布式文件系統(tǒng)都是利用google的方案自行實現(xiàn)的。這個方案的優(yōu)點是可用性比較高，基本上基于硬盤的應用都可以處理，可用范圍就比較廣泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相關介紹，大致有一些認識。

首先是文檔比較少而出現(xiàn)的問題倒不少;然后是目前這些還沒有一個能稱得上是穩(wěn)定版本，如果有的話，估計也就是其中一些收費的版本。因為磁盤存儲乃是致關重要，所以目前建議還是不要輕易把這些東西部署到重要的地方。假如非常想使用的話，最好是做好充分測試，確保它的功能完全能夠滿足需要;然后還要想辦法在傳統(tǒng)的文件系統(tǒng)中做好完全的備份，以免造成損失。

另外可以提的一個東西是memcached，這個東西實現(xiàn)了內(nèi)存的分布式共享，穩(wěn)定度貌似比以上這些分布式文件系統(tǒng)要穩(wěn)定。不過是完全基于內(nèi)存的，如果數(shù)據(jù)量不是很大，可以一試。

2、手工使用文件路徑分散存儲

這個結構通常使用在web靜態(tài)文件中，就以這種情形作為例子。

如果這些文件數(shù)量比較大，可以通過分散文件路徑，把某個文件的訪問指定到特定的一臺或幾臺服務器上。例如：

1)采用域名的分散策略

例如使用a.xxx.com/b.xxx.com...來區(qū)分標記為a或b的一系列文件，這些文件存儲的時候，依然按照標記，存到a或b的服務器上。這個策略將區(qū)分機器的任務交由dns服務器來執(zhí)行，擴容時會相應輕松。這需要web項目初期就規(guī)劃好這些東東，后期才轉用域名策略的成本比較高甚至不可以實現(xiàn)。

2)采用目錄的分散策略

假如域名初期并沒有規(guī)劃使用域名策略，那么可以采用代理服務器來進行目錄級的劃分。比如一般存儲大量文件時，因為文件系統(tǒng)的限制以及效率問題，都會按照一定規(guī)則劃分了很多級的目錄，按這些目錄拆分機器也并不是困難的事情。這種架構的問題在于代理服務器的性能和可靠性問題，需要在這點上稍下一點功夫。

以上這兩個方案，都要自行制定策略實現(xiàn)分散同步傳輸，傳輸一般可以歸納為推送和抓取兩種辦法，同步的話可以采用日志同步(把要同步的數(shù)據(jù)記入日志，通過日志記錄來傳輸相應文件)、比較同步(使用rsync等同步軟件)或即時同步(有新的修改就立刻傳輸);另外要實現(xiàn)單點故障剔除的話，首先找一個策略把文件存儲到多個節(jié)點上，例如，a.xxx.com或目錄a的文件相應也存到b和c節(jié)點;然后在環(huán)境中使用故障剔除技術(lvs或nginx等)，就可以解決問題，例如：采用域名的話，可以采用lvs，缺點是使用的機器就會成倍增加;亦可再用一級代理服務器，缺點是會犧牲性能。采用目錄的話，因為本身就用到了代理服務器，所以只要存儲得當，實現(xiàn)比較容易。