分散式物件儲存和分散式檔案系統具有很強烈的對比性
分散式物件儲存是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來管理，這就幾乎可以實現無限擴大的後設資料儲存量！
對於未來的多主架構我也是瞭解這麼多，讓我們對分散式儲存未來發展能有所瞭解！
[前往讀位元組的知乎——瞭解更多關於大資料的知識(https://www.zhihu.com/people/fangshun/answers])
公眾號 "讀位元組" 大資料（技術、架構、應用）的深度，專業解讀
