說(shuō)說(shuō)分布式文件存儲(chǔ)系統(tǒng)

作者：左琴 2017-07-18 09:51:36

存儲(chǔ)

存儲(chǔ)軟件

分布式 分布式文件存儲(chǔ)系統(tǒng)主要被分為三種類(lèi)型：分布式文件存儲(chǔ)、塊存儲(chǔ)、對(duì)象存儲(chǔ)。這三種存儲(chǔ)系統(tǒng)都有著自己的特點(diǎn)和適用場(chǎng)景。

創(chuàng)新互聯(lián)專(zhuān)注于霍林郭勒網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供霍林郭勒營(yíng)銷(xiāo)型網(wǎng)站建設(shè)，霍林郭勒網(wǎng)站制作、霍林郭勒網(wǎng)頁(yè)設(shè)計(jì)、霍林郭勒網(wǎng)站官網(wǎng)定制、微信小程序定制開(kāi)發(fā)服務(wù)，打造霍林郭勒網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供霍林郭勒網(wǎng)站排名全網(wǎng)營(yíng)銷(xiāo)落地服務(wù)。

[[197109]]

分布式文件存儲(chǔ)系統(tǒng)主要被分為三種類(lèi)型：分布式文件存儲(chǔ)、塊存儲(chǔ)、對(duì)象存儲(chǔ)。這三種存儲(chǔ)系統(tǒng)都有著自己的特點(diǎn)和適用場(chǎng)景。

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

很幸運(yùn)自己在過(guò)去的工作中對(duì)這三種系統(tǒng)都有過(guò)或深或淺的接觸，因此有了想要把這其中零散的知識(shí)點(diǎn)做一個(gè)整理，畢竟才疏學(xué)淺，希望跟有興趣的同學(xué)共同進(jìn)步。

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

系統(tǒng)架構(gòu)

對(duì)于目前所接觸到的主流分布式文件系統(tǒng)來(lái)看，根據(jù)系統(tǒng)架構(gòu)的特點(diǎn)大多可做如下劃分：

• 有無(wú)中心管理節(jié)點(diǎn)
• 存儲(chǔ)節(jié)點(diǎn)是否有主從之分

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

集群管理

集群管理主要解決以下幾個(gè)問(wèn)題：

• 存儲(chǔ)節(jié)點(diǎn)上下線(xiàn)通知，自動(dòng)剔除不可用節(jié)點(diǎn)等
• 集群各節(jié)點(diǎn)心跳和狀態(tài)的維護(hù)，是否健康，可讀可寫(xiě)
• 維護(hù)系統(tǒng)的邏輯模型，如分區(qū)、用戶(hù)等邏輯概念的關(guān)系，如swift系統(tǒng)中提到的region，zone，node，patition等邏輯概念及從屬關(guān)系

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

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

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

而講到的另外一種查詢(xún)的方式，一般不會(huì)集中去存儲(chǔ)文件映射的元數(shù)據(jù)信息，因?yàn)殡S著集群規(guī)模的增長(zhǎng),元數(shù)據(jù)服務(wù)器較為容易成為瓶頸,所以常常是采用多個(gè)元數(shù)據(jù)服務(wù)機(jī)制去解決這個(gè)問(wèn)題。

存儲(chǔ)引擎

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

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

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

存儲(chǔ)副本

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

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

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

一致性協(xié)議

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

• 強(qiáng)一致性：當(dāng)更新操作在某個(gè)副本上執(zhí)行成功后，之后所有的讀操作都要能夠獲得***的數(shù)據(jù)。
• 弱一致性：當(dāng)更新某數(shù)據(jù)時(shí)，用戶(hù)讀到***的數(shù)據(jù)需要一段時(shí)間。
• 最終一致性：它是一種特殊形式的弱一致性。它不能保證當(dāng)某個(gè)數(shù)據(jù)X更新后，在所有后續(xù)對(duì)X的操作能夠看到新數(shù)據(jù)，而是在經(jīng)過(guò)一個(gè)時(shí)間片段之后，才能保證。在這個(gè)時(shí)間片段內(nèi)，數(shù)據(jù)可能是不一致的。

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

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

兩種方式的優(yōu)缺點(diǎn)后續(xù)會(huì)從實(shí)現(xiàn)以及性能角度展開(kāi)說(shuō)明。

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

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

有中心節(jié)點(diǎn)的系統(tǒng)，數(shù)據(jù)恢復(fù)大多是由中心節(jié)點(diǎn)負(fù)責(zé)控制調(diào)度，因?yàn)橹挥兴写鎯?chǔ)節(jié)點(diǎn)和存儲(chǔ)介質(zhì)的全局信息，而每個(gè)存儲(chǔ)節(jié)點(diǎn)能做的就是等待中心節(jié)點(diǎn)的調(diào)度執(zhí)行數(shù)據(jù)恢復(fù)的任務(wù)

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

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

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

異常處理

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

通信協(xié)議

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

采用HTTP協(xié)議，從系統(tǒng)的使用和可測(cè)性角度來(lái)說(shuō)是有利的，但同時(shí)也意味著一次請(qǐng)求到達(dá)不同的節(jié)點(diǎn)都會(huì)經(jīng)過(guò)不斷的解析和封裝，勢(shì)必是會(huì)有些損耗的，尤其是在跟rpc協(xié)議相比，之前做過(guò)性能對(duì)比，但對(duì)于存儲(chǔ)系統(tǒng)來(lái)說(shuō)，這點(diǎn)延時(shí)就不算什么了。

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

讀寫(xiě)流程

分布式文件系統(tǒng)的架構(gòu)決定了其讀寫(xiě)流程必然會(huì)有些不同，如有中心節(jié)點(diǎn)的系統(tǒng)，客戶(hù)端的寫(xiě)操作首先會(huì)到中心節(jié)點(diǎn)獲取該寫(xiě)到哪個(gè)節(jié)點(diǎn)的信息，而對(duì)于有主從之分的存儲(chǔ)節(jié)點(diǎn)來(lái)說(shuō)，客戶(hù)端的讀操作一般會(huì)優(yōu)去主節(jié)點(diǎn)讀。。。

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

新聞標(biāo)題：說(shuō)說(shuō)分布式文件存儲(chǔ)系統(tǒng)
分享路徑：http://m.fisionsoft.com.cn/article/coiegie.html