【內(nèi)容聲明】本文收集整理于互聯(lián)網(wǎng),不確保內(nèi)容真實性和質(zhì)量度,僅供參考!若有服務器產(chǎn)品相關問題,請咨詢[YINGSOO]在線客服,獲取專業(yè)解答!

　　【推薦產(chǎn)品】數(shù)據(jù)存儲服務器丨游戲云服務器丨云服務器維護丨香港cn2服務器

　　【精選文章】如何選云主機配置帶寬大??？其實很好選

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

　　其中分布式文件存儲和對象存儲是聯(lián)系非常緊密的，大多對象存儲系統(tǒng)都是在分布式文件系統(tǒng)基礎上實現(xiàn)的。

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

　　對于分布式文件存儲系統(tǒng)，我們常常根據(jù)它的特點和功能模塊做劃分，才能從各個不同的角度去學習、了解和實現(xiàn)一個分布式文件存儲系統(tǒng)

　　系統(tǒng)架構

　　對于目前所接觸到的主流分布式文件系統(tǒng)來看，根據(jù)系統(tǒng)架構的特點大多可做如下劃分：

　　有無中心管理節(jié)點

　　存儲節(jié)點是否有主從之分

　　這兩種架構都有著自己明顯的優(yōu)勢和缺點，對整個分布式文件系統(tǒng)的實現(xiàn)起決定作用，直接影響采用何種一致性協(xié)議保持備份間的一致性，以及集群如何管理，數(shù)據(jù)丟失或損壞該如何恢復、數(shù)據(jù)清理等等功能的實現(xiàn)，后面會單獨對此做闡述和說明

　　集群管理

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

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

　　集群各節(jié)點心跳和狀態(tài)的維護，是否健康，可讀可寫

　　維護系統(tǒng)的邏輯模型，如分區(qū)、用戶等邏輯概念的關系，如swift系統(tǒng)中提到的region，zone，node，patition等邏輯概念及從屬關系

　　數(shù)據(jù)定位

　　即客戶端如何根據(jù)文件名快速查找到數(shù)據(jù)的位置并獲取到文件內(nèi)容，目前接觸到分布式存儲系統(tǒng)在解決數(shù)據(jù)定位問題上，有兩種方式。一種可以稱作為計算方式，即最常見的hash算法定位，另外一種可稱為查詢時，將映射關系存儲起來，通過查詢的方式定位文件位置。

　　其中，哈希算法是最常見的數(shù)據(jù)分布方式,其方法是按照數(shù)據(jù)的某一特征計算哈希值,并將哈希值與機器中的磁盤建立映射關系，以swift為代表的一致性哈希算法也屬于此類的改良品種，用哈希的方式優(yōu)點是明顯的，不需要記錄的元信息,任何節(jié)點只需要知道哈希函數(shù)的計算方式即可以知道數(shù)據(jù)存儲的位置，但是也存在一些問題，及增加或減少節(jié)點勢必或多或少都會引起數(shù)據(jù)的遷移。

　　而講到的另外一種查詢的方式，一般不會集中去存儲文件映射的元數(shù)據(jù)信息，因為隨著集群規(guī)模的增長,元數(shù)據(jù)服務器較為容易成為瓶頸,所以常常是采用多個元數(shù)據(jù)服務機制去解決這個問題。

　　文件存儲管理系統(tǒng) - 存儲引擎

　　存儲引擎，即數(shù)據(jù)最終是以何種形式存儲在單機系統(tǒng)上。大多分布式文件系統(tǒng)的底層存儲形式都是依賴本地文件系統(tǒng)接口，如Swift，Ceph等底層文件存儲，畢竟分布式文件系統(tǒng)本身已經(jīng)很復雜了，很難從上層一直到底層存儲都自己去實現(xiàn)，而本地文件系統(tǒng)已經(jīng)很成熟完善，所以大部分分布式文件系統(tǒng)都是依賴本地文件系統(tǒng)去實現(xiàn)的。YINGSOO：www.sddonglingsh.com

　　對不同的分布式文件系統(tǒng)在單機上的存儲格式是不一樣的，以swift為例它是以一個個文件的形式存儲在單機文件系統(tǒng)中，即一個文件就對應在單機上也就是一個文件(忽略對象存儲那一層的大文件映射關系)，而還有另外一種分布式文件系統(tǒng)，在單機文件系統(tǒng)中是多個文件合并存儲，以一個大文件的形式存儲在單機文件系統(tǒng)中，同時記錄每個文件的操作日志，可以理解為對小文件進行了合并。

　　這兩種存儲方式都有各自的利弊，并有各自的適用場景。對文件進行合并的日志文件系統(tǒng)，雖然會有文件的二次定位問題，但它有一個明顯的優(yōu)勢，即小文件的讀寫性能會有明顯的提升，而對于swift采用的這種不進行合并存儲的系統(tǒng)來說，實現(xiàn)相對容易，但小文件的讀寫磁盤必然會成為性能的瓶頸。

　　存儲副本

　　副本(replica/copy)的存在是為保證分布式系統(tǒng)中數(shù)據(jù)冗余，在不同的節(jié)點上持久化同一份數(shù)據(jù),當出現(xiàn)某一個節(jié)點的存儲的數(shù)據(jù)丟失時,可以從副本上讀到數(shù)據(jù)，是分布式系統(tǒng)解決數(shù)據(jù)丟失異常的唯一手段。

　　對于可靠性要求高的數(shù)據(jù)進行三備份存儲，甚至要求副本跨分區(qū)存儲;而對于可靠性要求低的數(shù)據(jù)，兩備份就能滿足需求。隨著存儲的數(shù)據(jù)量增加，多副本存儲會導致存儲成本增加，因此有了糾刪碼的方式，可以極大的節(jié)省存儲成本，并且可以提升數(shù)據(jù)的可靠性。

　　多副本存儲引發(fā)出了一些需要解決的關鍵問題，如副本數(shù)據(jù)的一致性，如何保證副本數(shù)量和位置正確等等。

　　一致性協(xié)議

　　一致性協(xié)議是分布式文件系統(tǒng)核心問題之一，說的是如何保持副本內(nèi)容的一致性。常見的三種一致性模型如下：

　　強一致性：當更新操作在某個副本上執(zhí)行成功后，之后所有的讀操作都要能夠獲得最新的數(shù)據(jù)。

　　弱一致性：當更新某數(shù)據(jù)時，用戶讀到最新的數(shù)據(jù)需要一段時間。

　　最終一致性：它是一種特殊形式的弱一致性。它不能保證當某個數(shù)據(jù)X更新后，在所有后續(xù)對X的操作能夠看到新數(shù)據(jù)，而是 在經(jīng)過一個時間片段之后，才能保證 。在這個時間片段內(nèi)，數(shù)據(jù)可能是不一致的。

　　在多個副本節(jié)點沒有主從之分的分布式系統(tǒng)中，數(shù)據(jù)一致性的保證往往由客戶端保證，這里的客戶端指的是分布式文件系統(tǒng)的接入層，如swift的proxy節(jié)點，swift采用的是Quorum 仲裁協(xié)議，即 R+W>N。Swift 默認配置是 N=3，W=2>N/2，R=1 或 2，即每個對象會存在 3 個副本，這些副本會盡量被存儲在不同區(qū)域的節(jié)點上;W=2 表示至少需要更新 2 個副本才算寫成功;當 R=1 時意味著某一個讀操作成功便立刻返回，此種情況下可能會讀取到舊版本(弱一致性模型);當 R=2 時，需要通過在讀操作請求頭中增加 x-newest=true 參數(shù)來同時讀取 2 個副本的元數(shù)據(jù)信息，然后比較時間戳來確定哪個是最新版本(強一致性模型)

　　而當多副本之間是有主從節(jié)點之分的系統(tǒng)中，數(shù)據(jù)的一致性大多由主節(jié)點保證，客戶端的寫請求發(fā)往主節(jié)點，主節(jié)點更新成功，同時將請求轉(zhuǎn)發(fā)至從節(jié)點，收到所有從節(jié)點的成功響應后，再返回成功(強一致模型)。

　　兩種方式的優(yōu)缺點后續(xù)會從實現(xiàn)以及性能角度展開說明。

　　數(shù)據(jù)恢復

　　對于有中心控制節(jié)點和無中心控制節(jié)點的分布式文件系統(tǒng)，數(shù)據(jù)恢復的實現(xiàn)也會大為不同

　　有中心節(jié)點的系統(tǒng)，數(shù)據(jù)恢復大多是由中心節(jié)點負責控制調(diào)度，因為只有它有存儲節(jié)點和存儲介質(zhì)的全局信息，而每個存儲節(jié)點能做的就是等待中心節(jié)點的調(diào)度執(zhí)行數(shù)據(jù)恢復的任務。APP網(wǎng)站租用香港服務器

　　無中心節(jié)點的系統(tǒng)，數(shù)據(jù)恢復的實現(xiàn)只能由各個存儲節(jié)點負責，如swift，根據(jù)ring的信息獲取副本的位置，通過數(shù)據(jù)恢復的進程，維持副本的數(shù)量和位置的正確性

　　數(shù)據(jù)清理

　　對于用戶調(diào)用刪除接口進行刪除的數(shù)據(jù)，是直接刪除?還是標記刪除?直接刪除固然是最簡潔方便的，但是同時也意味著如果是誤刪的情況下數(shù)據(jù)無法找回，而對于標記刪除，需要一個額外的模塊對標記刪除的數(shù)據(jù)進行掃描，再實施真正的刪除，在某種程度上減少了數(shù)據(jù)丟失的風險。

　　異常處理

　　文件存儲管理系統(tǒng)異常處理是分布式系統(tǒng)中需要處理的核心問題之一，只有合理處理了各種可預知的和未知的異常，才能保證分布式存儲系統(tǒng)的可用性和可靠性。常見的異常有節(jié)點宕機、網(wǎng)絡異常、硬件故障等等，異常處理不恰當導致不可用和系統(tǒng)性能問題都有經(jīng)歷過，而對于分布式文件系統(tǒng)改如何處理遺產(chǎn)個，以及如何通過壓力異常測試保證系統(tǒng)可用性等等，都是比較大的話題，在后續(xù)進行展開。

　　通信協(xié)議

　　通信協(xié)議主要指的是分布式文件系統(tǒng)中節(jié)點之間的通信主要采取何種協(xié)議，以swift為例的節(jié)點間所有的通信都采用的是HTTP協(xié)議，另外一種常見的通信協(xié)議即采用RPC協(xié)議進行通信。

　　采用HTTP協(xié)議，從系統(tǒng)的使用和可測性角度來說是有利的，但同時也意味著一次請求到達不同的節(jié)點都會經(jīng)過不斷的解析和封裝，勢必是會有些損耗的，尤其是在跟rpc協(xié)議相比，之前做過性能對比，但對于存儲系統(tǒng)來說，這點延時就不算什么了。

　　采用RPC協(xié)議，在代碼實現(xiàn)上來說是簡單方便的，但跟HTTP協(xié)議比起來，在做一些分層的功能和性能測試時，可測性會受到影響，就是稍微麻煩一些的，但總的說來還可接受。

　　讀寫流程

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

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

　　本公司推出香港服務器、美國服務器等獨立海外主機產(chǎn)品，滿足客戶對租用海外服務器多樣性需求，不僅很好的解決了香港、美國及東南亞一帶的訪問速度問題，而且也兼顧了國內(nèi)用戶的訪問速度，方便在國內(nèi)進行數(shù)據(jù)的上傳和維護工作。

　　本文關鍵詞：文件存儲管理系統(tǒng),文件存儲管理

　　YINGSOO提供優(yōu)質(zhì)的香港云服務器以及其他境外服務器產(chǎn)品，品類包括站群服務器、高防服務器、云主機等，配置齊全，有多種套餐可供選擇，企業(yè)可以按照自身的業(yè)務需求來選擇相應的服務器租用和套餐，YINGSOO服務器機房線路穩(wěn)定可靠，提供7*24小時技術服務，如您有需求，歡迎在頁面右方咨詢在線QQ客服。全國統(tǒng)一服務熱線：400-630-3752

　　YINGSOO臺灣主機哪家好優(yōu)惠中!介紹新客戶,返現(xiàn)16%!

　　9年臺灣主機哪家好服務商,超過1200家企業(yè)共同選擇,五星機房品質(zhì),帶控制臺.立即申請臺灣主機哪家好3天免費試用,,專業(yè)數(shù)據(jù)災備方案,24小時貼心服務

　　http://www.sddonglingsh.com/products/cloud-tw.html

　　韓國主機租用商,選知名品牌YINGSOO

　　9年韓國主機租用商業(yè)務運營經(jīng)驗,1200家企業(yè)客戶共同選擇.韓國Korea Telecom機房核心合作伙伴,機房帶寬資源充足,到國內(nèi)速度平均在80ms左右.

　　http://www.sddonglingsh.com/products/cloud-kr.html

版權聲明：本站文章來源標注為YINGSOO的內(nèi)容版權均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。