分布式檔案存儲系統主要被分為三種類型：分布式檔案存儲、塊存儲、對象存儲。這三種存儲系統都有着自己的特點和适用場景。
其中分布式檔案存儲和對象存儲是聯系非常緊密的，大多對象存儲系統都是在分布式檔案系統基礎上實作的。
很幸運自己在過去的工作中對這三種系統都有過或深或淺的接觸，是以有了想要把這其中零散的知識點做一個整理，畢竟才疏學淺，希望跟有興趣的同學共同進步。
對于分布式檔案存儲系統，我們常常根據它的特點和功能子產品做劃分，才能從各個不同的角度去學習、了解和實作一個分布式檔案存儲系統
系統架構
對于目前所接觸到的主流分布式檔案系統來看，根據系統架構的特點大多可做如下劃分：
有無中心管理節點
存儲節點是否有主從之分
這兩種架構都有着自己明顯的優勢和缺點，對整個分布式檔案系統的實作起決定作用，直接影響采用何種一緻性協定保持備份間的一緻性，以及叢集如何管理，資料丢失或損壞該如何恢複、資料清理等等功能的實作，後面會單獨對此做闡述和說明
叢集管理
叢集管理主要解決以下幾個問題：
存儲節點上下線通知，自動剔除不可用節點等
叢集各節點心跳和狀态的維護，是否健康，可讀可寫
維護系統的邏輯模型，如分區、使用者等邏輯概念的關系，如swift系統中提到的region，zone，node，patition等邏輯概念及從屬關系
資料定位
即用戶端如何根據檔案名快速查找到資料的位置并擷取到檔案内容，目前接觸到分布式存儲系統在解決資料定位問題上，有兩種方式。一種可以稱作為計算方式，即最常見的hash算法定位，另外一種可稱為查詢時，将映射關系存儲起來，通過查詢的方式定位檔案位置。
其中，雜湊演算法是最常見的資料分布方式,其方法是按照資料的某一特征計算哈希值,并将哈希值與機器中的磁盤建立映射關系，以swift為代表的一緻性雜湊演算法也屬于此類的改良品種，用哈希的方式優點是明顯的，不需要記錄的元資訊,任何節點隻需要知道哈希函數的計算方式即可以知道資料存儲的位置，但是也存在一些問題，及增加或減少節點勢必或多或少都會引起資料的遷移。
而講到的另外一種查詢的方式，一般不會集中去存儲檔案映射的中繼資料資訊，因為随着叢集規模的增長,中繼資料伺服器較為容易成為瓶頸,是以常常是采用多個中繼資料服務機制去解決這個問題。
存儲引擎
存儲引擎，即資料最終是以何種形式存儲在單機系統上。大多分布式檔案系統的底層存儲形式都是依賴本地檔案系統接口，如swift，ceph等底層檔案存儲，畢竟分布式檔案系統本身已經很複雜了，很難從上層一直到底層存儲都自己去實作，而本地檔案系統已經很成熟完善，是以大部分分布式檔案系統都是依賴本地檔案系統去實作的。
對不同的分布式檔案系統在單機上的存儲格式是不一樣的，以swift為例它是以一個個檔案的形式存儲在單機檔案系統中，即一個檔案就對應在單機上也就是一個檔案(忽略對象存儲那一層的大檔案映射關系)，而還有另外一種分布式檔案系統，在單機檔案系統中是多個檔案合并存儲，以一個大檔案的形式存儲在單機檔案系統中，同時記錄每個檔案的記錄檔，可以了解為對小檔案進行了合并。
這兩種存儲方式都有各自的利弊，并有各自的适用場景。對檔案進行合并的日志檔案系統，雖然會有檔案的二次定位問題，但它有一個明顯的優勢，即小檔案的讀寫性能會有明顯的提升，而對于swift采用的這種不進行合并存儲的系統來說，實作相對容易，但小檔案的讀寫磁盤必然會成為性能的瓶頸。
存儲副本
副本(replica/copy)的存在是為保證分布式系統中資料備援，在不同的節點上持久化同一份資料,當出現某一個節點的存儲的資料丢失時,可以從副本上讀到資料，是分布式系統解決資料丢失異常的唯一手段。
對于可靠性要求高的資料進行三備份存儲，甚至要求副本跨分區存儲;而對于可靠性要求低的資料，兩備份就能滿足需求。随着存儲的資料量增加，多副本存儲會導緻存儲成本增加，是以有了糾删碼的方式，可以極大的節省存儲成本，并且可以提升資料的可靠性。
多副本存儲引發出了一些需要解決的關鍵問題，如副本資料的一緻性，如何保證副本數量和位置正确等等。
一緻性協定
一緻性協定是分布式檔案系統核心問題之一，說的是如何保持副本内容的一緻性。常見的三種一緻性模型如下：
強一緻性：當更新操作在某個副本上執行成功後，之後所有的讀操作都要能夠獲得最新的資料。
弱一緻性：當更新某資料時，使用者讀到最新的資料需要一段時間。
最終一緻性：它是一種特殊形式的弱一緻性。它不能保證當某個資料x更新後，在所有後續對x的操作能夠看到新資料，而是在經過一個時間片段之後，才能保證。在這個時間片段内，資料可能是不一緻的。
在多個副本節點沒有主從之分的分布式系統中，資料一緻性的保證往往由用戶端保證，這裡的用戶端指的是分布式檔案系統的接入層，如swift的proxy節點，swift采用的是quorum 仲裁協定，即 r+w>n。swift 預設配置是 n=3，w=2>n/2，r=1 或 2，即每個對象會存在 3 個副本，這些副本會盡量被存儲在不同區域的節點上;w=2 表示至少需要更新 2 個副本才算寫成功;當 r=1 時意味着某一個讀操作成功便立刻傳回，此種情況下可能會讀取到舊版本(弱一緻性模型);當 r=2 時，需要通過在讀操作請求頭中增加 x-newest=true 參數來同時讀取 2 個副本的中繼資料資訊，然後比較時間戳來确定哪個是最新版本(強一緻性模型)
而當多副本之間是有主從節點之分的系統中，資料的一緻性大多由主節點保證，用戶端的寫請求發往主節點，主節點更新成功，同時将請求轉發至從節點，收到所有從節點的成功響應後，再傳回成功(強一緻模型)。
兩種方式的優缺點後續會從實作以及性能角度展開說明。
資料恢複
對于有中心控制節點和無中心控制節點的分布式檔案系統，資料恢複的實作也會大為不同
有中心節點的系統，資料恢複大多是由中心節點負責控制排程，因為隻有它有存儲節點和存儲媒體的全局資訊，而每個存儲節點能做的就是等待中心節點的排程執行資料恢複的任務
無中心節點的系統，資料恢複的實作隻能由各個存儲節點負責，如swift，根據ring的資訊擷取副本的位置，通過資料恢複的程序，維持副本的數量和位置的正确性
資料清理
對于使用者調用删除接口進行删除的資料，是直接删除?還是标記删除?直接删除固然是最簡潔友善的，但是同時也意味着如果是誤删的情況下資料無法找回，而對于标記删除，需要一個額外的子產品對标記删除的資料進行掃描，再實施真正的删除，在某種程度上減少了資料丢失的風險。
異常處理
異常處理是分布式系統中需要處理的核心問題之一，隻有合理處理了各種可預知的和未知的異常，才能保證分布式存儲系統的可用性和可靠性。常見的異常有節點當機、網絡異常、硬體故障等等，異常處理不恰當導緻不可用和系統性能問題都有經曆過，而對于分布式檔案系統改如何處理遺産個，以及如何通過壓力異常測試保證系統可用性等等，都是比較大的話題，在後續進行展開。
通信協定
通信協定主要指的是分布式檔案系統中節點之間的通信主要采取何種協定，以swift為例的節點間所有的通信都采用的是http協定，另外一種常見的通信協定即采用rpc協定進行通信。
采用http協定，從系統的使用和可測性角度來說是有利的，但同時也意味着一次請求到達不同的節點都會經過不斷的解析和封裝，勢必是會有些損耗的，尤其是在跟rpc協定相比，之前做過性能對比，但對于存儲系統來說，這點延時就不算什麼了。
采用rpc協定，在代碼實作上來說是簡單友善的，但跟http協定比起來，在做一些分層的功能和性能測試時，可測性會受到影響，就是稍微麻煩一些的，但總的說來還可接受。
讀寫流程
分布式檔案系統的架構決定了其讀寫流程必然會有些不同，如有中心節點的系統，用戶端的寫操作首先會到中心節點擷取該寫到哪個節點的資訊，而對于有主從之分的存儲節點來說，用戶端的讀操作一般會優去主節點讀。。。
以上，簡單的給自己列了一個架構，然後再分别将其填滿。靡不有初，鮮克有終，希望自己可以堅持!
作者：左琴
來源：51cto