分佈式存儲單主、多主和無中心架構的特徵與趨勢

分佈式對象存儲和分佈式文件系統具備很強烈的對比性

分佈式對象存儲是key/value的存儲模式，以restful訪問方式爲主，幾乎處於扁平化的存儲形式，經過地址做爲主鍵，訪問、更新的文件對象做爲值。文件自己能夠分佈式分片，可是key/value的訪問都是原子性，文件不能追加數據，亦不能隨機訪問文件的片斷，必須整存整取。幾乎大多數的互聯網web資源訪問都適合這種模式，例如：大廠們都雲存儲OSS。

分佈式文件系統不一樣於對象存儲，結構上是目錄資源管理的樹形層次，主要是以模擬或鏈接Unix/Linux文件系統爲主，分佈式文件系統就特別適合在文件塊追加數據，或者在文件塊中隨機找到偏移量，讀取一小段數據。

分佈式對象存儲 PK 分佈式文件系統的優劣也很鮮明，前者特別適合海量小文件的快速存與讀，所以大多數互聯網不太大的照片、文件資源存儲都適合分佈式對象存儲系統；但對於大數據計算過程管理、大文件隨機讀取和追加，就特別適合分佈式文件系統了，像Hadoop的批處理計算底層使用分佈式文件系統（HDFS）也是這個緣由！

好了，先贅述了一些概念！那麼直入主題：

分佈式文件系統的發展，master/slave架構佔了很大一部分，例如hdfs,zookeeper這些hadoop生態圈的工具，基本上是主從架構的.而以glusterfs爲表明的無中心架構也在逐漸發展，可是想了解的是，將來會出現多主架構，仍是會使用glusterfs這種無中心架構呢？由於單節點的應用如今愈來愈成爲一個瓶頸了，又或者說，仍是有其餘的替代方案呢？

對於Master/Slave的集中式架構細究起來也分爲不一樣的形式

（一）協調管理方面：

主備式：例如HDFS的namenode就是管理者一主一備，主壞，備上；

選舉式：管理者是被多個備選推舉的，例如Elasticsearch，zookeeper的主節點選舉。

分佈式數據庫有管理節點負責調度和管理數據節點，也有數據節點負責數據讀寫。

（二）數據方面：

數據集中式管理：例如：HDFS的namenode管理着具備完整語義的元數據樹形結構，那麼就能對數據塊讀寫的節點進行集中分配，指哪打哪！

數據非集中式管理：例如：Elasticsearch等不少分佈式存儲的數據分片機制使用Hash分片存儲訪問，不用主節點來集中分配，這樣主節點就不復雜，只要按照約定協調好不一樣節點的工做任務就能夠了，可是若一個節點掛了，整個集羣的數據都要再分配一次！

再看看對等式架構：

不一樣於master/slave集中式架構，有一個主節點協調全部從節點，對等式架構集羣中每一個節點都是平等的，例如：glusterfs就是典型的對等式架構，經過Hash算法來肯定誰在當下的一次請求中做爲頭目，主導其餘多個節點的數據處理。

其實不管是一箇中心的主從式，仍是無中心的對等式，都存在明顯的硬傷：

資源管理方面對比：例如：HDFS的namenode元數據是用樹形管理，具備完整語義的文件資源管理系統，想知道哪一個節點的狀態，處理那個節點的數據，就很是容易；

偏偏是無中心架構是萬萬都作不到的事情，對數據進行一次管理，就要整個集羣的各個節點從頭走一遍，很消耗資源，所以很難見到大多數的無中心存儲架構對外隨意支持數據遷移，要命呢！

可靠性方面對比：一箇中心的主從式架構要是主掛了，雖然有備的能夠頂上來，可是這個過程不是想象中那麼可靠，首先主備切換有中斷時間，其次有時候會出現所謂的腦裂，並且備的再掛掉，整個集羣就game over了；

無中心的問題在於每一個節點都很獨立很自治，這就存在信息遲滯問題，一個節點的狀態或配置信息變化了，整個集羣獲取變化的過程會很慢，這就沒法作到分佈式一致性了。

擴展性方面對比：主從式的另一個瓶頸來自主節點的資源消耗問題，內存是有限的，元數據管理的文件數量是有限制的，HDFS又是這一問題的帶頭大哥，它適合支持較大文件，若太多的小文件會致使內存中的元數據樹太大而內存溢出，固然了存儲文件特別龐大也會出現內存瓶頸；另外支持的元數據文件也是有Linux的最大文件數限制的，對於像Google這種管理着超級大數據業務的企業或機構固然必定要考慮這個事情。

偏偏無中心的架構就不存在主的瓶頸問題，能夠實現線性的擴張。但無主也好，單主也好，只要使用hash進行約定式的節點數據分配，都存在hash可能致使的數據傾斜問題，傾斜問題就會帶來某一個數據節點的若大壓力，所以數據管理員須要時時關注這一問題。

從將來分佈式存儲的發展看，多主架構的出現是必定的

多主架構的實現不只徹底解決了單主的瓶頸問題以外，還防止了無中心架構的全部缺點，固然這種架構從分佈式存儲的將來說確定是最好的一種選擇了！關鍵是到底有沒有這種架構呢？

目前只能說又是Google了！Colossus File System瞭解一下，GFS的下一代的繼任者，能夠說是GFS 2.0版本吧！

我對Golossus的瞭解也是所知有限，Google對這方面的細節也還沒有公諸於衆，我也只能把知道的一點點進行腦補再講出來：

Colossus File System是經過key/value替代樹形結構實現元數據存儲和管理，那麼Colossus就能夠實現多個主節點了！所謂的分佈式元數據管理。關鍵點在於——將原來元數據完整語義的樹形結構轉換成爲完整語義的鍵值存儲結構，同時還保證操做的原子性。

最牛逼的是它的架構：Colossus的key/value是基於BigTable，而BigTable必須基於GFS，可是Colossus又是GFS的升級改造！

咱們再翻譯成開源的Hadoop來理解：HDFS2的namenode對元數據的管理基於HBase，HBase基於HDFS，可是HDFS2又是HDFS的升級改造！

是否是已經繞進去了！咱們用一張圖來表現其邏輯，固然這張圖也只是腦補圖！

Colossus File System的Master Server須要管理全部的數據節點D Server（相似GFS的ChunkServer），管理的元數據都存儲在BigTable上，而BigTable的基礎設施是一個微型的GFS，它纔是元數據（Metadata）的真正存儲地點（Metadata ChunkServer）。就好像氫彈得經過原子彈來驅動一個道理！

那麼GFS中Master Server的元數據樹，就只是管理打包好的元數據文件塊了，這個文件量就真不大了！而真正的元數據都是由它的上層BigTable使用key/value來管理，這就幾乎能夠實現無限擴大的元數據存儲量！

對於將來的多主架構我也是瞭解這麼多，讓咱們對分佈式存儲將來發展能有所瞭解！

前往讀字節的知乎——瞭解更多關於大數據的知識

公衆號「讀字節」 分佈式，大數據，軟件架構的深度，專業解讀