數據的可靠性是任何一個存儲系統的第一要務，之後才是根據實際業務場景提供相應的接口和服務。單機系統上，數據的可靠性主要依賴於底層硬件設施，除了存儲設備本身的可靠性，通常還搭配RAID技術作為冗餘方案。分佈式系統面臨的問題則要複雜得多。借鑑至RAID技術，有副本，糾刪碼等冗餘方案，可以保證數據的可靠性，但同時也引入了新的問題：系統可用性和數據一致性。CAP理論（有一定的適用場景）指出，一致性（C），可用性（A）和分區問題（P），三者無法同時保證，而一般認為，P是不可避免的，這就意味著一致性和可用性這兩個目標是互相沖突的。可以看到，分佈式系統的複雜主要就在於檢測和處理各種故障問題，還需要權衡系統的可用性和數據的一致性。在此基礎上才考慮擴容，服務等級，安全等問題。
本文介紹分佈式存儲系統設計中的幾個主要問題和考慮點，會提及一些算法和策略，但不做展開，感興趣可自行查閱相關文章，或等待後續文章補充。
1 業務場景
目前，流行的存儲業務需求主要可歸類成三種：
- 塊存儲：Block Storage，提供Linux的塊設備接口，Qemu的塊驅動接口，雲硬盤接口等，實際使用時，性能方面重點關注的是時延
- 對象存儲：Object Storage，提供鍵值（Key-Value）接口，如GET，PUT，DEL等，案例如Swift，S3等，性能方面重點關注吞吐量
- 文件存儲：File Storage，提供POSIX文件系統或自定義的文件系統服務，支持目錄及文件屬性等功能，案例如GFS，HDFS，CephFS等
存儲業務的性能需求，一般可通過數據的冷熱，快慢，大小進行考慮，不同業務通常都對應不同的性能要求。
分佈式存儲對於單節點的底層存儲要求，跟以上的業務需求類似。目前大部分都基於現有的本地成熟文件系統，小部分則是基於塊設備，去掉了文件系統支持，自行管理存儲空間，還有一種，目前最少，它要求底層硬件直接提供鍵值接口。
通常，一個系統都只滿足其中的一項需求，這也是類Unix系統的一個基本設計理念：程序應該小而專一。如何使用和組合由用戶自行完成，當然，這也帶來了一定的運維成本。有些分佈式存儲，則提供多種，比如Ceph，同時提供這三種服務。Ceph架構中最核心的部件實際只有一個：RADOS，一切對象化，然後對上提供各類服務的接口。這也是Ceph所提的統一存儲的概念。這一定程度上也滿足了類Unix的設計理念。當然，實際應用中，同時需要使用多種業務的場景可能不見得有太多，而且Ceph本身還沒完全適應生產環境，這也是目前專用系統依然使用比較廣泛的原因之一。
2 中心化 vs 去中心化
任何一個分佈式系統都需要中心化管理，因此所謂的去中心化，要點就在於中心點承擔的職責大小，而這裡面最主要的一個職責就是元數據的管理，而最主要的元數據莫過於數據和位置的映射關係。傳統的中心點都需要維護數據和位置的映射關係，讀寫訪問都需要經過中心點進行統一調度，中心點的性能瓶頸，可用性，可靠性，伸縮性等方面如何保障，都面臨極大的挑戰。而現在的去中心化，則無需維護數據和位置的映射，客戶端通過算法計算即可獲得相應映射關係，之後到相應節點直接進行訪問即可，中心點職責被大幅減弱。由此可見，是否去中心化的一個重要標準為：是否維護數據和位置的映射關係。
去中心化後，無需維護數據和位置的映射關係，並不意味著沒有了映射關係，而是採用算法固定了映射關係。同時，為了保證可靠性，一般還使用數據冗餘技術，如副本（Replica），糾刪碼（EC）。算法本身則確保數據分佈的均衡程度。但是，一旦節點發生增刪（如擴容，故障），即用於算法計算的輸入條件發生了變化，部分映射關係就發生了變化，即數據需要遷移。當然，遷移一般在系統內部自主完成，如Ceph所提供的自管理/自恢復特性。一般，去中心化的系統都會假定故障是一個常態化事件，這是就需要重點評估遷移效率以及造成的影響。比如Ceph在實際使用過程中，最難處理的部分就是數據遷移以及其帶來的影響。
去中心化，一定程度上也意味著各自為政，需要統一管理的部分，比如統計分析，數據跟蹤，權限控制，服務等級管理等，就變得比較複雜。在數據遷移方面，中心化因為有統一管理的信息，只需恢復故障部分的數據即可，而去中心化的系統，由於映射關係的變化，將導致一些非故障數據也可能需要遷移。比如將集群規模擴大一倍，為了重均衡，理論上就有一半數據需要遷移，而中心化系統就沒有此類問題。
去中心化系統是使用算法來確保數據分佈的均衡度的，這在數據量較小的情況下體現並不明顯，性能方面也同樣，在集群規模較小的情況下，去中心化的系統所宣稱的高性能實際上無法體現，甚至可能更差。
可以看到，兩者之間的主要優缺點：
- 中心化：能夠統一調度控制，故障處理和恢復比較容易，可維護性高，但性能瓶頸，單點故障問題以及擴展能力等方面需要著重考慮
- 去中心化：能夠提供較高數據訪問能力，沒有單點問題，擴展能力出色，且規模越大，性能表現越好，但其故障處理比較複雜，可維護性也存在挑戰
中心化和去中心化有各自的優勢和不足，設計時應根據業務需求進行選擇。
3 數據冗餘
分佈式系統都是由多個節點組成的，規模越大，異常狀況越可能發生，比如網絡異常，硬盤故障，宕機等。為了保證系統的可靠性和可用性，分佈式系統必須使用副本來提高可用性，以降低異常狀況帶來的影響。當然，其中的讀寫過程都是在分佈式系統內部完成的，對用戶透明。但是，這也帶來了新的問題：多個副本之間的一致性問題。最簡單的策略是：寫時要求全部副本寫完才返回，讀則隨意讀取一份即可。當寫比較多時，這種方式將導致響應時間極大增加，更極端的情況，如果此時某個副本節點異常了，等待可能就是無限期的，可用性問題依然存在。為了更進一步的解決該問題，基於Quorum投票的冗餘算法就被提出。
3.1 Quorum/NWR
- N：副本總數
- W：寫要返回時，需保證成功的最少副本數
- R：讀時，需讀取的最少副本數
有兩條準則必須保證：
- W > N/2：最小寫副本需達到半數以上
- W+R > N：也為R > N-W，可能未寫入的最大副本數為N-W，只要讀取的副本數大於該數，即可保證至少有一份最新副本
每個副本都需要有版本號，用來區分副本的新舊情況。同時，還需要有類似心跳檢測的協議（比如，租約lease），以便知道副本所在節點的健康狀態，防止無限期等待。
NWR一般是通過設置來完成的，常見的設置有N3-W2-R2，對一致性的要求比較高，而N3-W2-R1則對讀一致性要求不高，還存在W1的情況，只需寫入一個即可返回，性能最好，但一致性保證最差。如何設置則取決於實際的業務需求。
不管什麼樣的設置，分佈式系統中最複雜的還是容錯處理，在某些節點出現異常的時候，以上策略如何進行重新適應就是問題。比如：
- N3-W2-R2：寫入時，一個成功，兩個失敗，整體應是返回失敗，寫入成功的副本必須經過處理，否則讀時（讀兩份副本），一定概率會讀到那份寫入成功的數據，但實際該份數據為髒數據，理論上應該丟棄
- N3-W3-R1：寫入時，兩個成功，另一個已實際寫入成功，但因網絡問題，超時返回失敗，此時整體應為失敗，數據需要回滾，這時需要警惕原超時的節點重新加入的處理，否則可能讀取新數據，而實際上是髒數據
- 後臺校驗：有時也稱為數據清洗，結合日誌系統，用於清除髒數據
- 寫併發：多個寫併發進行時，如果此時出現異常，則回滾可能會變得非常複雜
Amazon的Dynamo，Swift等系統就使用了NWR策略。
3.2 Replica
無論W和R是什麼樣的設置，N一般都為3，即所謂的三副本，這種數據冗餘方式的存儲成本也比較高，即要存儲1TB數據，實際需使用3TB空間。在副本複製方面，一般有同步複製和異步複製之分，NWR算法中兩者是同時被使用的，即W的部分要求同步寫入，剩餘的N-W部分採用異步方式寫入。從用戶角度看，異步方式比較友好，但內部的一致性則需要額外的工作來保證。另外，從角色上看，還有主從副本（主從服務器，也稱為primary-secondary協議）之分。NWR算法並沒有規定副本之間的角色定位，通常認為是平等的，併發情況下的複雜度也因此增大。主從副本，則以依次傳遞的方式進行拷貝，即：所有的寫都需經過主副本，主副本完成後，再傳遞至從副本，從副本的寫可以是異步的。如果主副本發生異常了，則從其他副本中選取一個作為主副本（選舉協議），當然，在切換過程中可能會存在一定的異常時間窗口。
Ceph採用的是類似主從副本的方式，複製方式則是同步+異步組合使用，它並沒有採用嚴格的NWR算法實現，不過依然採用了三副本的數據冗餘方式。數據的一致性，則是通過內部的自管理和數據清洗來完成。
3.3 RAID
由於分佈式存儲技術中的很多策略都與RAID技術有類似相通的地方，比如Striping條帶化，副本，以及後文的EC糾刪碼，故本節簡略介紹一下RAID技術。RAID，Redundant Array of Independent Disk，獨立冗餘磁盤陣列，根據配置可實現數據冗餘和提高性能的目的。常見配置如下：
- RAID0：Striping數據到多塊硬盤上，即一份數據被拆成多份同時寫到硬盤上，可顯著提高性能，由於沒有冗餘，可靠性最差，空間利用率100%
- RAID1：Mirror鏡像方式，與上文提及的副本類似，即一份數據需要寫到兩塊硬盤上，不進行Striping，可靠性最好，但性能最差，空間利用率50%
- RAID5：增加一塊校驗盤，其餘硬盤採用Striping方式寫入，是RAID0和RAID1的折衷方案，各方面兼顧較好，空間利用率為(N-1)/N
- RAID10：RAID1+RAID0的組合，實現上，將硬盤分組，組內使用RAID1鏡像，組間則使用RAID0的Striping，結合了RAID0和RAID1的優點，空間利用率50%
在分佈式存儲系統中，RAID技術在某種程度上將被取代（實際上是在軟件層面上實現了RAID的功能），但分佈式存儲系統更具優勢，比如，在可靠性方面，允許多個節點故障；數據重建方面，無需停機，多個節點可以同時參與恢復，性能也大大提升。比如Ceph系統，甚至建議取消RAID，原因是Ceph的自恢復特性（多副本/EC+自管理），已經使得RAID變得無關緊要。
3.4 EC
將數據拆分成一個個對象，並存儲到不同節點上，從而實現Striping，這相當於RAID0，而多副本的冗餘策略則相當於RAID1。另一種冗餘技術，EC（Erasure-Coding），一般譯為糾刪碼，則與RAID5類似，能夠較大的利用存儲空間，降低存儲成本。但缺點也顯而易見：冗餘碼的計算是通過軟件實現的，效率相對低下。實際使用時，一般採用冷熱分層策略，對於較熱的數據，重點考慮其性能，故採用多副本方式；而對於冷數據，則重點考慮存儲成本，故採用EC方式提高空間利用率。
4 數據分佈和重均衡
一般情況下，分佈式系統都會考慮節點之間的數據分佈均衡情況，在整個系統集群健康的情況下，有很多算法都能協助達到該目標，比如一致性哈希，CRUSH算法等。但是，分佈式系統中，節點故障是常見的事件，也就是說集群的拓撲情況可能會經常發生變化，加上系統擴容等因素，節點數量總會發生增減。這種情況下，為了達到再均衡的狀態，系統內部就可能需要做數據遷移，這個過程就稱為重均衡（Re-balancing）。理想的狀態是數據遷移量越少越好。比如新節點加入時，數據只從舊節點流向新節點，舊節點之間沒有數據流動。
任何一個數據分佈算法的目標都是一致的，都需要考慮如下因素：
- 均衡分佈：數據儘可能均衡的分佈在各個節點上，儘量避免過於空閒或過於繁忙的節點出現
- 節點增減：節點加入或離開時引起的數據遷移量應儘可能小
- 容錯能力：數據副本應該分散在不同的故障域，充分降低數據丟失的風險
中心化系統相對比較容易做，節點減少時，只需將節點上的數據按一定規則分佈到現有節點上即可；增加節點時則只需決定哪些數據要放到新節點上，甚至不做任何遷移，僅加大該節點後續的負載程度，也能達到最終的負載均衡。
在去中心化的系統中，重均衡就相對比較複雜，甚至可能會出現一些無意義的數據遷移。由於數據分佈直接取決於算法，而算法又和集群的拓撲情況緊密相關，拓撲一發生變化，數據分佈也需要隨著發生變化。比如，一般的一致性哈希算法，節點（對應token）和數據都採用相同的計算方式，數據則放置離它最近（比較計算後的值）的下一個節點上，一旦某個節點發生故障，只需將原故障節點中的數據轉移到下一個節點即可，影響相對較小，但下一個節點在一定時間內會出現較大的負載壓力。CRUSH算法影響的節點範圍，相對一致性哈希算法會大一些，這也直接導致需要遷移的數據（包括本來不受影響的）量，也會比較大。
5 監測
以上介紹了一些降低故障影響以及故障恢復的策略，比如數據冗餘，數據重均衡等，但故障是否發生，即故障檢測，是後續處理的關鍵。對於具有自管理和自恢復的系統，怎麼合理判斷故障發生了，更是重要。常見的故障包括系統宕機，硬盤故障，網絡異常等，其中網絡異常的判斷尤為困難，丟包或短時間內的網絡異常，是常見的情況。簡單粗暴的判斷此類網絡異常為故障，將可能導致系統內數據遷移不斷髮生，並最終影響整系統的可用性。
一般情況下，會設置一些監測節點，用於收集節點相關信息，其中就包括節點的健康狀態，該過程稱為心跳檢測。心跳檢測一般有超時（Timeout）和租約（Lease）等策略，其中，租約策略是目前比較常用的策略。
除了健康狀態信息外，其他的節點信息，通常可作為統計，分析，調度和決策等用途。
6 小結
以上主題都可以對應到分佈式存儲系統的幾個關鍵考量點上：
- 可靠性：數據不能丟失，這是所有存儲系統的第一要務。理論上，數據丟失的概率始終是存在的，故系統需具備容錯能力，以應對各種故障問題，儘可能降低數據丟失的風險
- 可用性：在規定時間內持續提供服務，容錯能力是保證該特性的主要技術手段，性能要求方面可採用多節點等方案來提高
- 一致性：總能訪問到最新數據。由於多節點的存在，數據副本之間如何保持一致就是個問題。可以看到，一致性和可用性這兩個目標是存在衝突的（詳見CAP理論）
- 伸縮性：也稱為擴展性，主要指增減節點的難易程度，通常指的是擴容的情況
- 性能：可認為是可用性的一個要求，如果系統無法提供相當的性能，則可視為不滿足可用性要求
其他的一些重要特性，如安全，服務等級（QoS）等，不在此討論。
原文地址：https://xupifu.github.io/2017/04/08/distributed-storage-system-topics/
閱讀更多 架構師筆記 的文章
