說說分散式文件存儲系統

作者：左琴

分散式文件存儲系統主要被分為三種類型：分散式文件存儲、塊存儲、對象存儲。這三種存儲系統都有著自己的特點和適用場景。

其中分散式文件存儲和對象存儲是聯繫非常緊密的，大多對象存儲系統都是在分散式文件系統基礎上實現的。

很幸運自己在過去的工作中對這三種系統都有過或深或淺的接觸，因此有了想要把這其中零散的知識點做一個整理，畢竟才疏學淺，希望跟有興趣的同學共同進步。

對於分散式文件存儲系統，我們常常根據它的特點和功能模塊做劃分，才能從各個不同的角度去學習、了解和實現一個分散式文件存儲系統

系統架構

對於目前所接觸到的主流分散式文件系統來看，根據系統架構的特點大多可做如下劃分：

有無中心管理節點

存儲節點是否有主從之分

這兩種架構都有著自己明顯的優勢和缺點，對整個分散式文件系統的實現起決定作用，直接影響採用何種一致性協議保持備份間的一致性，以及集群如何管理，數據丟失或損壞該如何恢復、數據清理等等功能的實現，後面會單獨對此做闡述和說明

集群管理

集群管理主要解決以下幾個問題：

存儲節點上下線通知，自動剔除不可用節點等

集群各節點心跳和狀態的維護，是否健康，可讀可寫

維護系統的邏輯模型，如分區、用戶等邏輯概念的關係，如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協議比起來，在做一些分層的功能和性能測試時，可測性會受到影響，就是稍微麻煩一些的，但總的說來還可接受。

讀寫流程

分散式文件系統的架構決定了其讀寫流程必然會有些不同，如有中心節點的系統，客戶端的寫操作首先會到中心節點獲取該寫到哪個節點的信息，而對於有主從之分的存儲節點來說，客戶端的讀操作一般會優去主節點讀。。。

以上，簡單的給自己列了一個框架，然後再分別將其填滿。靡不有初，鮮克有終，希望自己可以堅持!

End.

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！