[[247858]]

常規(guī)的存儲(chǔ)設(shè)計(jì)方法主要有以下幾類。

• 無中心的存儲(chǔ)設(shè)計(jì)，如GlusterFS。
• 有中心的存儲(chǔ)設(shè)計(jì)，如Hadoop。
• 基于數(shù)據(jù)庫(kù)的存儲(chǔ)設(shè)計(jì)，如GridFS和HBase。
• 繞過元數(shù)據(jù)的存儲(chǔ)設(shè)計(jì)，如FastDFS。

下面我們逐一講述。

無中心的存儲(chǔ)設(shè)計(jì)：GlusterFS

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

• 兼容POSIX文件系統(tǒng)：?jiǎn)螜C(jī)上的應(yīng)用程序無需修改就可以放到GlusterFS運(yùn)行。
• 沒有中心節(jié)點(diǎn)：不存在單點(diǎn)故障和性能瓶頸。
• 擴(kuò)展能力：因?yàn)闆]有中心節(jié)點(diǎn)，所以GlusterFS的擴(kuò)展能力無限，擴(kuò)展多少臺(tái)服務(wù)器都沒有問題。

我們不討論P(yáng)OSIX兼容的優(yōu)劣，集中通過GlusterFS來討論無中心節(jié)點(diǎn)設(shè)計(jì)中普遍遇到的一些難點(diǎn)。

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

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

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

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

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

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

簡(jiǎn)單總結(jié)一下，以GlusterFS為代表的無中心設(shè)計(jì)帶來的一些問題如下圖所示。

有中心的存儲(chǔ)設(shè)計(jì)：Hadoop

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

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

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

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

3. 為可伸縮性服務(wù)，可以伸縮存儲(chǔ)節(jié)點(diǎn)，元信息節(jié)點(diǎn)無需伸縮。

然而有如此設(shè)計(jì)優(yōu)點(diǎn)的Hadoop為什么不適合在公有云領(lǐng)域提供服務(wù)呢？

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

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

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

因此，做有中心的云存儲(chǔ)時(shí)，通常的做法是完全拋棄掉原先的單中心節(jié)點(diǎn)設(shè)計(jì)，引入一些其他的設(shè)計(jì)。

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

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

W，R，N選多少合適

第一種選擇2，2，3，一共三副本，寫入兩份成功，讀取時(shí)成功讀取兩份算成功。但是其中一臺(tái)機(jī)器下線的話，會(huì)出現(xiàn)數(shù)據(jù)讀不出來的情況，導(dǎo)致數(shù)據(jù)不可用。

第二種選擇4，4，6或者6，6，9，能夠容忍單機(jī)故障。但機(jī)器越多，平均響應(yīng)時(shí)間越長(zhǎng)。

失敗的寫入會(huì)污染數(shù)據(jù)

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

下面，我們簡(jiǎn)單總結(jié)一下以Hadoop為代表的有中心的存儲(chǔ)設(shè)計(jì)存在的問題。

基于數(shù)據(jù)庫(kù)的分布式存儲(chǔ)設(shè)計(jì)：GridFS、HBase

GridFS

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

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

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

2.擁有MongoDB的全部?jī)?yōu)點(diǎn)：在線存儲(chǔ)、高可用、可伸縮、跨機(jī)房備份；

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

GridFS的缺點(diǎn)如下所述。

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

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

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

對(duì)GridFS的總結(jié)如下。

HBase

前面提到Hadoop因?yàn)镹ameNode容量問題，所以不適合用來做小文件存儲(chǔ)，那么HBase是否合適呢？

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

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

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

但缺點(diǎn)才是最關(guān)鍵的，HBase有以下缺點(diǎn)。

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

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

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

繞過問題的存儲(chǔ)設(shè)計(jì)：FastDFS

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

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

1.結(jié)構(gòu)簡(jiǎn)單，元數(shù)據(jù)節(jié)點(diǎn)壓力低；

2.擴(kuò)容簡(jiǎn)單，擴(kuò)容后無需重新平衡。

FastDFS的缺點(diǎn)如下。

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

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

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

總結(jié)

幾種存儲(chǔ)設(shè)計(jì)可以總結(jié)如下。