【轉】存儲系統那些事

存儲系統從其與生俱來的使命來講，就難以擺脫複雜系統的魔咒。不管是從單機時代的文件系統，仍是後來C/S或B/S結構下數據庫這樣的存儲中間件興起，仍是現在煊赫一時的雲存儲服務來講，存儲都很複雜，並且是愈來愈複雜。

存儲爲何會複雜，要從什麼是存儲談起。存儲這個詞很是平凡，存儲 + 計算（操做）就構成了一個樸素的計算機模型。簡單來講，存儲就是負責維持計算系統的狀態的單元。從維持狀態的角度，咱們會有最樸素的可靠性要求。好比單機時代的文件系統，機器斷電、程序故障、系統重啓等常規的異常，文件系統必須能夠正確地應對，甚至對於磁盤扇區損壞，文件系統也須要考慮儘可能將損失降到最低。對於大部分的業務程序而言，你只須要重點關注業務的正常分支流程就行，對於出乎意料的狀況，一般只需拋出一個錯誤，告訴用戶你不應這麼玩。可是對於存儲系統，你須要花費絕大部分精力在各類異常狀況的處理上，甚至你應該認爲，這些龐雜的、多樣的錯誤分支處理，纔是存儲系統的「正常業務邏輯」。

到了互聯網時代，有了C/S或B/S結構，存儲系統又有了新指標：可用性。爲了保證服務質量，那些用戶看不見的服務器程序必須時時保持在線，最好作到邏輯上是不宕機的（可用性100%）。服務器程序怎麼才能作到高可用性？答案是存儲中間件。沒有存儲中間件，意味着全部的業務程序，都必須考慮每作一步就對狀態進行持久化，以便本身掛掉後另外一臺服務器（或者本身重啓後），知道以前工做到哪裏了，接下去應該作些什麼。可是對狀態進行持久化（也就是存儲）會很是繁瑣，若是每一個業務都本身實現，負擔無疑很是沉重。但若是有了高可用的存儲中間件，服務器端的業務程序就只需操做存儲中間件來更新狀態，經過同時啓動多份業務程序的實例作互備和負載均衡，很容易實現業務邏輯上不宕機。

因此，數據庫這樣的存儲中間件出現基本上是歷史必然。儘管數據庫很通用，但它決不會是惟一的存儲中間件。好比業務中用到的富媒體（圖片、音視頻、Office文檔等），咱們不多會去存儲到數據庫中，更多的時候咱們會把它們放在文件系統裏。可是單機時代誕生的文件系統，真的是最適合存儲這些富媒體數據的麼？不，文件系統須要改變，由於：

1. 伸縮性。單機文件系統的第一個問題是單機容量有限，在存儲規模超過一臺機器可管理的時候，應該怎麼辦。

2. 性能瓶頸。一般，單機文件系統在文件數目達到臨界點後，性能會快速降低。在4TB的大容量磁盤愈來愈普及的今天，這個臨界點至關容易到達。

3. 可靠性要求。單機文件系統一般只是單副本的方案，可是今天單副本的存儲早已沒法知足業務的可靠性要求。數據須要有冗餘（比較經典的作法是3副本），而且在磁盤損壞時及早修復丟失的數據，以免全部的副本損壞形成數據丟失。

4. 可用性要求。單機文件系統一般只是單副本的方案，在該機器宕機後，數據就不可讀取，也不可寫入。

在分佈式存儲系統出現前，有一些基於單機文件系統的改良版本被一些應用採納。好比在單機文件系統上加 RAID5 作數據冗餘，來解決單機文件系統的可靠性問題。假設 RAID5 的數據修復時間是1天（實際上每每作不到，尤爲是業務系統自己壓力比較大的狀況下，留給 RAID 修復用的磁盤讀寫帶寬頗有限），這種方案單機的可靠性大概是100年丟失一次數據（便可靠性是2個9）。看起來尚可？可是你得當心兩種狀況。一種是你的集羣規模變大，你仍然沿用這個土方法，好比你如今有 100 臺這樣的機器，那麼就會變成1年就丟失一次數據。另外一種狀況是若是實際數據修復時間是 3 天，那麼單機的可靠性就直降至4年丟失一次數據，100臺就會是15天丟失一次數據。這個數字顯然沒法讓人接受。

Google GFS 是不少人閱讀的第一份分佈式存儲的論文，這篇論文奠基了 3 副本在分佈式存儲系統裏的地位。隨後 Hadoop 參考此論文實現了開源版的 GFS —— HDFS。但關於 Hadoop 的 HDFS 實際上業界有很多誤區。GFS 的設計有很強的業務背景特徵，自己是用來作搜索引擎的。HDFS 更適合作日誌存儲和日誌分析（數據挖掘），而不是存儲海量的富媒體文件。由於：

1. HDFS 的 block 大小爲 64M，若是文件不足 64M 也會佔用 64M。而富媒體文件大部分仍然很小，好比圖片常規尺寸在 100K 左右。有人可能會說我能夠調小 block 的尺寸來適應，但這是不正確的作法，HDFS 的架構是爲大文件而設計的，不可能簡單經過調整 block 大小就能夠知足海量小文件存儲的需求。

2. HDFS 是單 Master 結構，這決定了它可以存儲的元數據條目數有限，伸縮性存在問題。固然做爲大文件日誌型存儲，這個瓶頸會很是晚才遇到；可是若是做爲海量小文件的存儲，這個瓶頸很快就會碰上。

3. HDFS 仍然沿用文件系統的 API 形式，好比它有目錄這樣的概念。在分佈式系統中維護文件系統的目錄樹結構，會遭遇諸多難題。因此 HDFS 想把 Master 擴展爲分佈式的元數據集羣並不容易。

分佈式存儲最容易處理的問題域仍是單鍵值的存儲，也就是所謂的 Key-Value 存儲。只有一個 Key，就意味着咱們能夠經過對 Key 作 Hash，或者對 Key 作分區，都可以讓請求快速定位到特定某一臺存儲機器上，從而轉化爲單機問題。這也是爲何在數據庫以後，會冒出來那麼多 NoSQL 數據庫。由於數據庫和文件系統同樣，最先都是單機的，在伸縮性、性能瓶頸（在單機數據量太大時）、可靠性、可用性上遇到了相同的麻煩。NoSQL 數據庫的名字其實並不恰當，他們更多的不是去 SQL，而是去關係（咱們知道數據庫更完整的稱呼是關係型數據庫）。有關係意味着有多個索引，也就是有多個 Key，而這對數據庫轉爲分佈式存儲系統來講很是不利。