雖然分布式存儲的存儲層和上傳下載這一層很重要，但在元數(shù)據(jù)方面有哪些選擇，這些選擇有什么優(yōu)缺點則更為重要。鑒于此，七牛首席架構師李道兵結合自己多年的實踐和思考，分享了存儲設計的幾大方法，并詳細分析了各種方法的利弊。

常規(guī)的存儲設計方法主要有以下幾類。

無中心的存儲設計，如GlusterFS。

有中心的存儲設計，如Hadoop。

基于數(shù)據(jù)庫的存儲設計，如GridFS和HBase。

繞過元數(shù)據(jù)的存儲設計，如FastDFS。

下面我們來逐一進行講述。

無中心的存儲設計：GlusterFS

目前，GlusterFS在互聯(lián)網(wǎng)行業(yè)中用的較少，在大型計算機中用的較多。它在設計上具有以下幾個特點。

兼容POSIX文件系統(tǒng)：單機上的應用程序無需修改就可以放到GlusterFS上運行。

沒有中心節(jié)點：不存在單點故障和性能瓶頸。

擴展能力：因為沒有中心節(jié)點，所以GlusterFS的擴展能力無限，擴展多少臺服務器都沒有問題。

我們不討論POSIX兼容的優(yōu)劣,集中通過GlusterFS來討論無中心節(jié)點設計中普遍遇到的一些難點。

1. 壞盤修復。無中心暗示著可通過key推算這個key的存儲位置。但是，磁盤壞了(單盤故障)怎么辦呢?直接的處理方式是去掉壞盤，換上新盤，將這些數(shù)據(jù)拷貝過來。這樣的處理方式在小型系統(tǒng)上非常適用。但是一個4T的Sata盤，即使在千兆網(wǎng)下寫入速度也只能達到100MB/s，修復時間會是11小時。考慮到一般的存儲滿指的是全部存儲量的80%，那么修復時間將達到8到9個小時，所以不適合用于大型系統(tǒng)。大型系統(tǒng)磁盤多，每天會壞很多塊磁盤。如果磁盤是同一批購買的，由于對稱設計，讀寫的特性很相似，那么在壞盤修復的八九個小時里，其他磁盤同時壞的概率非常高。這時，整個系統(tǒng)的可靠性會比較低，只能達到6個9或7個9。如果想達到更高的可靠性，只能通過瘋狂增加副本數(shù)這種會讓成本大量提高的方法來解決。

GlusterFS本身不用這種修復設計，它的修復方式是在讀磁盤時發(fā)現(xiàn)有壞塊就觸發(fā)修復，但這種設計的修復時間會更長。該如何回避掉這個問題呢?最簡單的方法是將磁盤分成多個區(qū)，確保每個區(qū)盡量小。例如，將4T盤分成50個區(qū)，每個區(qū)只有80GB，并且記錄各個區(qū)的一些元信息。在我們從key推算存儲位置時，先計算出這個 key 所在區(qū)的編號，再通過剛才的元信息獲得這個區(qū)對應的機器、磁盤和目錄。這樣帶來的好處是，在磁盤壞了的時候，不用等換盤就可以開始修復，并且不一定要修復到同一塊磁盤上，可以修復到有空間的多塊磁盤上，從而得到一種并發(fā)的修復能力。如果將4T盤分成50個區(qū)(每個區(qū)80G)，那么修復時間就可以從8到9個小時縮減到13分鐘左右。

2. 擴容。如前所述，在無中心節(jié)點的設計中，從key可以推算它存儲的位置，并且我們要求key是均勻Hash的。這時，如果集群規(guī)模從一百臺擴容到二百臺，會出現(xiàn)什么問題呢?Hash是均勻的，意味著新加的一百臺機器的存儲負載要和以前的一致，有一半的數(shù)據(jù)要進行遷移。但集群很大時，數(shù)據(jù)遷移過程中所花的時間通常會很長，這時會出現(xiàn)網(wǎng)絡擁塞。同時數(shù)據(jù)遷移過程中的讀寫邏輯會變得非常復雜。解決方法是多加一些測試，改善代碼質量，不要出Bug。還有一種方法是，保持容量固定，盡量不要擴容，但這與互聯(lián)網(wǎng)的風格(從很小的模型做起，慢慢將它擴大化)不相符。

3. 不支持異構存儲。提供云存儲服務的公司必然會面臨一個問題，有很多客戶存儲的文件非常小，而另外很多客戶存儲的文件非常大。小文件通常伴隨著很高的IOPS需求，比較簡單的做法是將Sata盤(100IOPS)換成SAS盤(300 IOPS)或者SSD盤(10000 IOPS以上)來得到更高的IOPS。但是對于無中心存儲，由于key是Hash的，所以根本不知道小文件會存在哪里，這時能提高IOPS的唯一辦法是加強所有機器的能力。例如，每臺機器中將10塊Sata盤、2塊SAS盤和1塊SSD盤作為一個整體加入緩存系統(tǒng)，提升系統(tǒng)的IOPS，但整體的成本和復雜性都會增加很多。另外一種方式是拼命擴大集群規(guī)模，這樣整體的IOPS能力自然會比較高。

類似的異構需求還包括某些客戶數(shù)據(jù)只想存兩份，而其他客戶數(shù)據(jù)則想多存幾份，這在無中心存儲中都很難解決。

4. 數(shù)據(jù)不一致的問題。比如要覆蓋一個key，基于Hash意味著要刪除一個文件，再重新上傳一個文件，新上傳的文件和之前的一個文件會在同一塊磁盤的同一個目錄下使用同樣的文件名。如果覆蓋時出現(xiàn)意外，只覆蓋了三個副本中的兩個或者一個，那么就很容易讀到錯誤的數(shù)據(jù)，讓用戶感覺到覆蓋沒有發(fā)生，但原始數(shù)據(jù)已經(jīng)丟失了。這是最難容忍的一個問題。解決方案是在寫入文件時，先寫一個臨時文件，最后再重命名修改。但由于是在分布式架構中，且跨機器操作，會導致邏輯的復雜性增加很多。

簡單總結一下，以GlusterFS為代表的無中心設計帶來的一些問題如下圖所示。

有中心的存儲設計：Hadoop

Hadoop的設計目標是存大文件、做offline分析、可伸縮性好。Hadoop的元數(shù)據(jù)存儲節(jié)點(NameNode節(jié)點)屬于主從式存儲模式，盡量將數(shù)據(jù)加載到內(nèi)存，能提高對數(shù)據(jù)的訪問性能。另外，放棄高可用，可進一步提高元數(shù)據(jù)的響應性能(NameNode的變更不是同步更新到從機，而是通過定期合并的方式來更新)。

Hadoop具有以下幾方面優(yōu)點。

1.為大文件服務。例如在塊大小為64MB時，10PB文件只需要存儲1.6億條數(shù)據(jù)，如果每條200Byte，那么需要32GB左右的內(nèi)存。而元信息的QPS也不用太高，如果每次QPS能提供一個文件塊的讀寫，那么1000QPS就能達到512Gb/s的讀寫速度，滿足絕大部分數(shù)據(jù)中心的需求。

2.為offline業(yè)務服務。高可用服務可以部分犧牲。

3.為可伸縮性服務。可以伸縮存儲節(jié)點，元信息節(jié)點無需伸縮。

然而有如此設計優(yōu)點的Hadoop為什么不適合在公有云領域提供服務呢?

1.元信息容量太小。在公有云平臺上，1.6億是個非常小的數(shù)字，單個熱門互聯(lián)網(wǎng)應用的數(shù)據(jù)都不止這些。1.6億條數(shù)據(jù)占用32GB內(nèi)存，100億條數(shù)據(jù)需要2000GB內(nèi)存，這時Hadoop就完全扛不住了。

2.元信息節(jié)點無法伸縮。元信息限制在單臺服務器，1000QPS甚至是優(yōu)化后的15000QPS的單機容量遠不能達到公有云的需求。

3.高可用不完美。就是前面所提到的NameNode問題，在業(yè)務量太大時，Hadoop支撐不住。

因此，做有中心的云存儲時，通常的做法是完全拋棄掉原先的單中心節(jié)點設計，引入一些其他的設計。

常見的是WRN算法，為數(shù)據(jù)準備多個樣本，寫入W份才成功，成功讀取R份才算成功，W+R大于N(其中N為總副本數(shù))。這樣就解決了之前提到的高可用問題，任何一個副本宕機，整個系統(tǒng)的讀寫都完全不受影響。

在這個系統(tǒng)里，利用這種技術有以下幾個問題需要注意。

1.W，R，N選多少合適。第一種選擇2，2，3，一共三副本，寫入兩份成功，讀取時成功讀取兩份算成功。但是其中一臺機器下線的話，會出現(xiàn)數(shù)據(jù)讀不出來的情況，導致數(shù)據(jù)不可用。第二種選擇4，4，6或者6，6，9，能夠容忍單機故障。但機器越多，平均響應時間越長。

2.失敗的寫入會污染數(shù)據(jù)。比如4，4，6的場景，如果寫入只成功了3份，那么這次寫入是失敗的。但如果寫入是覆蓋原來的元數(shù)據(jù)，就意味著現(xiàn)在有三份正確的數(shù)據(jù)，有三份錯誤的數(shù)據(jù)，無法判斷哪份數(shù)據(jù)正確，哪份數(shù)據(jù)錯誤?；乇艿姆椒ㄊ菍懭霐?shù)據(jù)帶版本(不覆蓋，只是追加)，即往數(shù)據(jù)庫里面插入新數(shù)據(jù)。有些云存儲的使用方法是對一個文件進行反復的修改，比如用M3U8文件直播。隨著直播進程的開始不停地更改文件，大概5秒鐘一次，持續(xù)一個小時文件會被修改720次。這時候從數(shù)據(jù)庫讀取文件信息時，就不再是讀1條記錄，而是每臺讀取720條記錄，很容易導致數(shù)據(jù)庫出現(xiàn)性能瓶頸。

下面，我們簡單總結一下以Hadoop為代表的有中心的存儲設計速存在的問題。

　　基于數(shù)據(jù)庫的分布式存儲設計：GridFS和HBase

GridFS

GridFS基于MongoDB，相當于一個文件存儲系統(tǒng)，是一種分塊存儲形式，每塊大小為255KB。數(shù)據(jù)存放在兩個表里，一個表是chunks，加上元信息后單條記錄在256KB以內(nèi);另一個表是files，存儲文件元信息。

GridFS的優(yōu)點如下所述。

1.可以一次性滿足數(shù)據(jù)庫和文件都需要持久化這兩個需求。絕大部分應用的數(shù)據(jù)庫數(shù)據(jù)需要持久化，用戶上傳的圖片也要做持久化，GridFS用一套設施就能滿足，可以降低整個運維成本和機器采購成本。

2.擁有MongoDB的全部優(yōu)點：在線存儲、高可用、可伸縮、跨機房備份。

3.支持Range GET，刪除時可以釋放空間(需要用MongoDB的定期維護來釋放空間)。

GridFS的缺點如下所述。

1.oplog耗盡。oplog是MongoDB上一個固定大小的表，用于記錄MongoDB上的每一步操作，MongoDB的ReplicaSet的同步依賴于oplog。一般情況下oplog在5GB～50GB附近，足夠支撐24小時的數(shù)據(jù)庫修改操作。但如果用于GridFS，幾個大文件的寫入就會導致oplog迅速耗盡，很容易引發(fā)secondary機器沒有跟上，需要手工修復，大家都知道，MongoDB的修復非常費時費力。簡單來說，就是防沖擊能力差，跟數(shù)據(jù)庫的設計思路有關，畢竟不是為文件存儲設計的。除了手工修復的問題，沖擊還會造成主從數(shù)據(jù)庫差異拉大，對于讀寫分離，或者雙寫后再返回等使用場景帶來不小的挑戰(zhàn)。

2.濫用內(nèi)存。MongoDB使用MMAP將磁盤文件映射到內(nèi)存。對于GridFS來說，大部分場景都是文件只需讀寫一次，對這種場景沒法做優(yōu)化，內(nèi)存浪費巨大，會擠出那些需要正常使用內(nèi)存的數(shù)據(jù)(比如索引)。這也是設計阻抗失配帶來的問題。

3.伸縮性問題。需要伸縮性就必須引入MongoDB Sharding，需要用files_id作Sharding，如果不修改程序，files_id遞增，所有的寫入都會壓入最后一組節(jié)點，而不是均勻分散。在這種情況下，需要改寫驅動，引入一個新的files_id生成方法。另外，MongoDBSharding在高容量壓力下的運維很痛苦。MongoDB Sharding需要分裂，分裂的時候響應很差，會導致整個服務陷入不可用的狀態(tài)。

對GridFS的總結如下。

　　HBase

前面提到Hadoop因為NameNode容量問題，所以不適合用來做小文件存儲，那么HBase是否合適呢?

HBase有以下優(yōu)點。

1.伸縮性、高可用都在底層解決了。

2.容量很大，幾乎沒有上限。

但缺點才是最關鍵的，HBase有以下缺點。

1.微妙的可用性問題。首先是Hadoop NameNode的高可用問題。其次，HBase的數(shù)據(jù)放在Region上，Region會有分裂的問題，分裂和合并的過程中Region不可用，不管用戶這時是想讀數(shù)據(jù)還是寫數(shù)據(jù)，都會失敗。雖然可以用預分裂回避這個問題，但這就要求預先知道整體規(guī)模，并且key的分布是近均勻的。在多用戶場景下，key均勻分布很難做到，除非舍棄掉key必須按順序這個需求。

2.大文件支持。HBase對10MB以上的大文件支持不好。改良方案是將數(shù)據(jù)拼接成大文件，然后HBase只存儲文件名、offset和size。這個改良方案比較實用，但在空間回收上需要補很多開發(fā)的工作。

應對方案是HBase存元數(shù)據(jù)，Hadoop存數(shù)據(jù)。但是，Hadoop是為offline設計的，對NameNode的高可用考慮不充分。HBase的Region分拆和合并會造成短暫的不可用，如果可以，最好做預拆，但預拆也有問題。如果對可用性要求低，那么這種方案可用。

繞過問題的存儲設計：FastDFS

Hadoop的問題是NameNode壓力過高，那么FastDFS的思路是給NameNode減壓。減壓方法是將NameNode的信息編碼到key中。對于范例URL:group1/M00/00/00/rBAXr1AJGF_3rCZAAAAEc45MdM850_big.txt來說，NameNode只需要做一件事，將group1翻譯成具體的機器名字，不用關心key的位置，只要關心組的信息所在的位置，而這個組的信息就放在key里面，就繞過了之前的問題。

FastDFS的優(yōu)點如下。

1.結構簡單，元數(shù)據(jù)節(jié)點壓力低。

2.擴容簡單，擴容后無需重新平衡。

FastDFS的缺點如下。

1.不能自定義key，這對多租戶是致命的打擊，自己使用也會降低靈活性。

2.修復速度：磁盤鏡像分布，修復速度取決于磁盤寫入速度，比如4TB的盤，100MB/s的寫入速度，至少需要11個小時。

3.大文件沖擊問題沒有解決。首先，文件大小有限制(不能超過磁盤大小);其次，大文件沒有分片，導致大文件的讀寫都由單塊盤承擔，所以對磁盤的網(wǎng)絡沖擊很大。

結語

本文基于七牛首席架構師李道兵在QCon會議上的演講內(nèi)容整理而成，著重對幾種存儲設計進行了比較全面的分析，總結如下。而關于分布式存儲的元數(shù)據(jù)設計還有很多更為細節(jié)的點和經(jīng)驗值得探討，留待日后慢慢與大家交流。