面向云數(shù)據(jù)庫(kù)，超低延遲文件系統(tǒng)PolarFS誕生了-創(chuàng)新互聯(lián)

隨著國(guó)內(nèi)首款Cloud Native自研數(shù)據(jù)庫(kù)POLARDB精彩亮相ICDE 2018的同時(shí)，作為其核心支撐和使能平臺(tái)的PolarFS文件系統(tǒng)的相關(guān)論文"PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database"也被數(shù)據(jù)庫(kù)頂級(jí)會(huì)議VLDB 2018錄用。8月，阿里云數(shù)據(jù)庫(kù)團(tuán)隊(duì)亮相于巴西里約召開的VLDB 2018，對(duì)整個(gè)業(yè)界起到了非常積極的影響。

在茄子河等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作定制網(wǎng)站制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),全網(wǎng)整合營(yíng)銷推廣,外貿(mào)網(wǎng)站建設(shè),茄子河網(wǎng)站建設(shè)費(fèi)用合理。

VLDB(Very Large Data Base)和另外兩大數(shù)據(jù)庫(kù)會(huì)議SIGMOD、ICDE構(gòu)成了數(shù)據(jù)庫(kù)領(lǐng)域的三個(gè)頂級(jí)會(huì)議。VLDB國(guó)際會(huì)議于1975在美國(guó)的弗雷明漢馬 (Framingham MA) 成立，是數(shù)據(jù)庫(kù)研究人員，供應(yīng)商，參與者，應(yīng)用開發(fā)者，以及用戶一年一度的頂級(jí)國(guó)際論壇。

VLDB主要由四個(gè)主題構(gòu)成，分別為：Core Database Technology (核心數(shù)據(jù)庫(kù)技術(shù))，Infrastructure for Information Systems (基礎(chǔ)設(shè)施信息系統(tǒng))，Industrial Applications and Experience (工業(yè)應(yīng)用與經(jīng)驗(yàn)) 以及 Experiments and Analyses（實(shí)驗(yàn)和分析）。

從09年至今的數(shù)據(jù)分析來看，VLDB的論文接受率總體是比較低，其中，核心數(shù)據(jù)庫(kù)主題中的論文接受率大概為16.7%；基礎(chǔ)設(shè)施信息系統(tǒng)方面的論文接受率大約為17.9%；工業(yè)應(yīng)用與經(jīng)驗(yàn)的論文接收比例近視為18%；而實(shí)驗(yàn)和分析部分的為19%左右。由此可見，論文被VLDB接收不是件容易的事情，必須是創(chuàng)新性很高，貢獻(xiàn)很大的論文才有機(jī)會(huì)被錄用。

本文著重介紹PolarFS的系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)。

背景

如同Oracle存在與之匹配的OCFS2，POLARDB作為存儲(chǔ)與計(jì)算分離結(jié)構(gòu)的一款數(shù)據(jù)庫(kù)，PolarFS承擔(dān)著發(fā)揮POLARDB特性至關(guān)重要的角色。PolarFS是一款具有超低延遲和高可用能力的分布式文件系統(tǒng)，其采用了輕量的用戶空間網(wǎng)絡(luò)和I／O棧構(gòu)建，而棄用了對(duì)應(yīng)的內(nèi)核棧，目的是充分發(fā)揮RDMA和NVMe SSD等新興硬件的潛力，極大地降低分布式非易失數(shù)據(jù)訪問的端到端延遲。目前，PolarFS的3副本跨節(jié)點(diǎn)寫入的訪問總延遲已經(jīng)非常接近單機(jī)本地PCIe SSD的延遲水平，成功地使得POLARDB在分布式多副本架構(gòu)下仍然能夠發(fā)揮出極致的性能。

設(shè)計(jì)初衷

針對(duì)數(shù)據(jù)庫(kù)設(shè)計(jì)分布式文件系統(tǒng)會(huì)帶來以下幾點(diǎn)好處：

計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)可以使用不同的服務(wù)器硬件，并能獨(dú)立地進(jìn)行定制。例如，計(jì)算節(jié)點(diǎn)不需要考慮存儲(chǔ)容量和內(nèi)存容量的比例，其嚴(yán)重依賴于應(yīng)用場(chǎng)景并且難以預(yù)測(cè)。

多個(gè)節(jié)點(diǎn)上的存儲(chǔ)資源能夠形成單一的存儲(chǔ)池，這能降低存儲(chǔ)空間碎化、節(jié)點(diǎn)間負(fù)載不均衡和空間浪費(fèi)的風(fēng)險(xiǎn)，存儲(chǔ)容量和系統(tǒng)吞吐量也能容易地進(jìn)行水平擴(kuò)展。

數(shù)據(jù)庫(kù)應(yīng)用的持久狀態(tài)可下移至分布式文件系統(tǒng)，由分布式存儲(chǔ)提供較高的數(shù)據(jù)可用性和可靠性。因此數(shù)據(jù)庫(kù)的高可用處理可被簡(jiǎn)化，也利于數(shù)據(jù)庫(kù)實(shí)例在計(jì)算節(jié)點(diǎn)上靈活快速地遷移。

此外，云數(shù)據(jù)庫(kù)服務(wù)也會(huì)因此帶來額外的收益：

云數(shù)據(jù)庫(kù)可以采用虛擬計(jì)算環(huán)境如KVM等部署形態(tài)，其更安全、更易擴(kuò)展和更易升級(jí)管理。

一些關(guān)鍵的數(shù)據(jù)庫(kù)特性，如一寫多讀實(shí)例、數(shù)據(jù)庫(kù)快照等可以通過分布式文件系統(tǒng)的數(shù)據(jù)共享、檢查點(diǎn)等技術(shù)而得以增強(qiáng)。

系統(tǒng)結(jié)構(gòu)

系統(tǒng)組件

PolarFS系統(tǒng)內(nèi)部主要分為兩層管理：

存儲(chǔ)資源的虛擬化管理，其負(fù)責(zé)為每個(gè)數(shù)據(jù)庫(kù)實(shí)例提供一個(gè)邏輯存儲(chǔ)空間。

文件系統(tǒng)元數(shù)據(jù)的管理，其負(fù)責(zé)在該邏輯存儲(chǔ)空間上實(shí)現(xiàn)文件管理，并負(fù)責(zé)文件并發(fā)訪問的同步和互斥。

PolarFS的系統(tǒng)結(jié)構(gòu)如圖所示：

• libpfs 是一個(gè)用戶空間文件系統(tǒng)庫(kù)，負(fù)責(zé)數(shù)據(jù)庫(kù)的I/O接入。

• PolarSwitch 運(yùn)行在計(jì)算節(jié)點(diǎn)上，用于轉(zhuǎn)發(fā)數(shù)據(jù)庫(kù)的I／O請(qǐng)求。

• ChunkServer 部署在存儲(chǔ)節(jié)點(diǎn)上，用于處理I／O請(qǐng)求和節(jié)點(diǎn)內(nèi)的存儲(chǔ)資源分布。

• PolarCtrl 是系統(tǒng)的控制平面，它包含了一組實(shí)現(xiàn)為微服務(wù)的管理者，相應(yīng)地Agent代理被部署到所有的計(jì)算和存儲(chǔ)節(jié)點(diǎn)上。

在進(jìn)一步介紹各部分之前，我們先來了解下PolarFS存儲(chǔ)資源的組織方法：

PolarFS的存儲(chǔ)資源管理單元分為3層：Volume、Chunk、Block。

Volume

Volume是為每個(gè)數(shù)據(jù)庫(kù)提供的獨(dú)立邏輯存儲(chǔ)空間，其上建立了具體文件系統(tǒng)供此數(shù)據(jù)庫(kù)使用，其大小為10GB至100TB，可充分適用于典型云數(shù)據(jù)庫(kù)實(shí)例的容量要求。

在Volume上存放了具體文件系統(tǒng)實(shí)例的元數(shù)據(jù)。文件系統(tǒng)元數(shù)據(jù)包括inode、directory entry和空閑資源塊等對(duì)象。由于POLARDB采用的是共享文件存儲(chǔ)架構(gòu)，我們?cè)谖募用鎸?shí)現(xiàn)了文件系統(tǒng)元數(shù)據(jù)一致性，在每個(gè)文件系統(tǒng)中除DB建立的數(shù)據(jù)文件之外，我們還有用于元數(shù)據(jù)更新的Journal文件和一個(gè)Paxos文件。我們將文件系統(tǒng)元數(shù)據(jù)的更新首先記錄在Journal文件中，并基于Paxos文件以disk paxos算法實(shí)現(xiàn)多個(gè)實(shí)例對(duì)Journal文件的互斥寫訪問。

Chunk

每個(gè)Volume內(nèi)部被劃分為多個(gè)Chunk，Chunk是數(shù)據(jù)分布的最小粒度，每個(gè)Chunk只存放于存儲(chǔ)節(jié)點(diǎn)的單個(gè)NVMe SSD盤上，其目的是利于數(shù)據(jù)高可靠和高可用的管理。典型的Chunk大小為10GB，這遠(yuǎn)大于其他類似的系統(tǒng)，例如GFS的64MB。

這樣做的優(yōu)勢(shì)是能夠有效地減少Volume的第一級(jí)映射元數(shù)據(jù)量的大?。ɡ纾?00TB的Volume只包含10K個(gè)映射項(xiàng)）。一方面，全局元數(shù)據(jù)的存放和管理會(huì)更容易；另一方面，這使得元數(shù)據(jù)可以方便地緩存在內(nèi)存中，從而有效避免關(guān)鍵I/O路徑上的額外元數(shù)據(jù)訪問開銷。

但這樣做的潛在問題是，當(dāng)上層數(shù)據(jù)庫(kù)應(yīng)用出現(xiàn)區(qū)域級(jí)熱點(diǎn)訪問時(shí)，Chunk內(nèi)熱點(diǎn)無法進(jìn)一步打散，但是由于我們的每個(gè)存儲(chǔ)節(jié)點(diǎn)提供的Chunk數(shù)量往往遠(yuǎn)大于節(jié)點(diǎn)數(shù)量（節(jié)點(diǎn):Chunk在1:1000量級(jí)），PolarFS可支持Chunk的在線遷移，并且服務(wù)于大量數(shù)據(jù)庫(kù)實(shí)例，因此可以將不同實(shí)例的熱點(diǎn)以及同一實(shí)例跨Chunk的熱點(diǎn)分布到不同節(jié)點(diǎn)以獲得整體的負(fù)載均衡。

Block

在ChunkServer內(nèi)，Chunk會(huì)被進(jìn)一步劃分為多個(gè)Block，其典型大小為64KB。Blocks動(dòng)態(tài)映射到Chunk 中來實(shí)現(xiàn)按需分配。Chunk至Block的映射信息由ChunkServer自行管理和保存，除數(shù)據(jù)Block之外，每個(gè)Chunk還包含一些額外Block用來實(shí)現(xiàn)Write Ahead Log。我們也將本地映射元數(shù)據(jù)全部緩存在ChunkServer的內(nèi)存中，使得用戶數(shù)據(jù)的I／O訪問能夠全速推進(jìn)。

下面我們?cè)敿?xì)介紹PolarFS的各個(gè)系統(tǒng)組件。

libpfs

libpfs是一個(gè)輕量級(jí)的用戶空間庫(kù)，PolarFS采用了編譯到數(shù)據(jù)庫(kù)的形態(tài)，替換標(biāo)準(zhǔn)的文件系統(tǒng)接口，這使得全部的I／O路徑都在用戶空間中，數(shù)據(jù)處理在用戶空間完成，盡可能減少數(shù)據(jù)的拷貝。這樣做的目的是避免傳統(tǒng)文件系統(tǒng)從內(nèi)核空間至用戶空間的消息傳遞開銷，尤其數(shù)據(jù)拷貝的開銷。這對(duì)于低延遲硬件的性能發(fā)揮尤為重要。

其提供了類Posix的文件系統(tǒng)接口（見下表），因而付出很小的修改代價(jià)即可完成數(shù)據(jù)庫(kù)的用戶空間化。

PolarSwitch

PolarSwitch是部署在計(jì)算節(jié)點(diǎn)的Daemon，它負(fù)責(zé)I/O請(qǐng)求映射到具體的后端節(jié)點(diǎn)。數(shù)據(jù)庫(kù)通過libpfs將I/O請(qǐng)求發(fā)送給PolarSwitch，每個(gè)請(qǐng)求包含了數(shù)據(jù)庫(kù)實(shí)例所在的Volume ID、起始偏移和長(zhǎng)度。PolarSwitch將其劃分為對(duì)應(yīng)的一到多個(gè)Chunk，并將請(qǐng)求發(fā)往Chunk所屬的ChunkServer完成訪問。

ChunkServer

ChunkServer部署在后端存儲(chǔ)節(jié)點(diǎn)上。一個(gè)存儲(chǔ)節(jié)點(diǎn)可以有多個(gè)ChunkServer。每個(gè)ChunkServer綁定到一個(gè)CPU核，并管理一個(gè)獨(dú)立的NVMe SSD盤，因此ChunkServer之間沒有資源爭(zhēng)搶。

ChunkServer負(fù)責(zé)Chunk內(nèi)的資源映射和讀寫。每個(gè)Chunk都包括一個(gè)WAL，對(duì)Chunk的修改會(huì)先進(jìn)Log再修改，保證數(shù)據(jù)的原子性和持久性。ChunkServer使用了3DXPoint SSD和普通NVMe SSD混合型WAL buffer，Log會(huì)優(yōu)先存放到更快的3DXPoint SSD中。

ChunkServer會(huì)復(fù)制寫請(qǐng)求到對(duì)應(yīng)的Chunk副本（其他ChunkServer）上，我們通過自己定義的Parallel Raft一致性協(xié)議來保證Chunk副本之間在各類故障狀況下數(shù)據(jù)正確同步和保障已Commit數(shù)據(jù)不丟失。

PolarCtrl

PolarCtrl是PolarFS集群的控制核心。其主要職責(zé)包括：

1. 監(jiān)控ChunkServer的健康狀況，確定哪些ChunkServer有權(quán)屬于PolarFS集群；

2. Volume創(chuàng)建及Chunk的布局管理（即Chunk分配到哪些ChunkServer）；

3. Volume至Chunk的元數(shù)據(jù)信息維護(hù)；

4. 向PolarSwitch推送元信息緩存更新；

5. 監(jiān)控Volume和Chunk的I/O性能；

6. 周期性地發(fā)起副本內(nèi)和副本間的CRC數(shù)據(jù)校驗(yàn)。

PolarCtrl使用了一個(gè)關(guān)系數(shù)據(jù)庫(kù)云服務(wù)用于管理上述metadata。

中心統(tǒng)控，局部自治的分布式管理

分布式系統(tǒng)的設(shè)計(jì)有兩種范式：中心化和去中心化。中心化的系統(tǒng)包括GFS和HDFS，其包含單中心點(diǎn)，負(fù)責(zé)維護(hù)元數(shù)據(jù)和集群成員管理。這樣的系統(tǒng)實(shí)現(xiàn)相對(duì)簡(jiǎn)單，但從可用性和擴(kuò)展性的角度而言，單中心可能會(huì)成為全系統(tǒng)的瓶頸。去中心化的系統(tǒng)如Dynamo完全相反，節(jié)點(diǎn)間是對(duì)等關(guān)系，元數(shù)據(jù)被切分并冗余放置在所有的節(jié)點(diǎn)上。去中心化的系統(tǒng)被認(rèn)為更可靠，但設(shè)計(jì)和實(shí)現(xiàn)會(huì)更復(fù)雜。

PolarFS在這兩種設(shè)計(jì)方式上做了一定權(quán)衡，采用了中心統(tǒng)控，局部自治的方式：PolarCtrl是一個(gè)中心化的master，其負(fù)責(zé)管理任務(wù)，如資源管理和處理控制平面的請(qǐng)求如創(chuàng)建Volume。ChunkServer負(fù)責(zé)Chunk內(nèi)部映射的管理，以及Chunk間的數(shù)據(jù)復(fù)制。當(dāng)ChunkServer彼此交互時(shí)，通過ParallelRaft一致性協(xié)議來處理故障并自動(dòng)發(fā)起Leader選舉，這個(gè)過程無需PolarCtrl參與。

PolarCtrl服務(wù)由于不直接處理高并發(fā)的I／O流，其狀態(tài)更新頻率相對(duì)較低，因而可采用典型的多節(jié)點(diǎn)高可用架構(gòu)來提供PolarCtrl服務(wù)的持續(xù)性，當(dāng)PolarCtrl因崩潰恢復(fù)出現(xiàn)的短暫故障間隙，由于PolarSwitch的緩存以及ChunkServer數(shù)據(jù)平面的局部元數(shù)據(jù)管理和自主leader選舉的緣故，PolarFS能夠盡量保證絕大部分?jǐn)?shù)據(jù)I／O仍能正常服務(wù)。

I/O 流程

下面我們通過一個(gè)I/O的處理來說明各組件的互動(dòng)過程。

PolarFS執(zhí)行寫I/O請(qǐng)求的過程如上圖所示：

1. POLARDB通過libpfs發(fā)送一個(gè)寫請(qǐng)求，經(jīng)由ring buffer發(fā)送到PolarSwitch。

2. PolarSwitch根據(jù)本地緩存的元數(shù)據(jù)，將該請(qǐng)求發(fā)送至對(duì)應(yīng)Chunk的主節(jié)點(diǎn)。

3. 新寫請(qǐng)求到達(dá)后，主節(jié)點(diǎn)上的RDMA NIC將寫請(qǐng)求放到一個(gè)提前分好的buffer中，并將該請(qǐng)求項(xiàng)加到請(qǐng)求隊(duì)列。一個(gè)I／O輪詢線程不斷輪詢這個(gè)請(qǐng)求隊(duì)列，一旦發(fā)現(xiàn)新請(qǐng)求到來，它就立即開始處理。

4. 請(qǐng)求通過SPDK寫到硬盤的日志block，并通過RDMA發(fā)向副本節(jié)點(diǎn)。這些操作都是異步調(diào)用，數(shù)據(jù)傳輸是并發(fā)進(jìn)行的。

5. 當(dāng)副本請(qǐng)求到達(dá)副本節(jié)點(diǎn)，副本節(jié)點(diǎn)的RDMA NIC同樣會(huì)將其放到預(yù)分buffer中并加入到復(fù)制隊(duì)列。

6. 副本節(jié)點(diǎn)上的I／O輪詢線程被觸發(fā)，請(qǐng)求通過SPDK異步地寫入Chunk的日志。

7. 當(dāng)副本節(jié)點(diǎn)的寫請(qǐng)求成功回調(diào)后，會(huì)通過RDMA向主節(jié)點(diǎn)發(fā)送一個(gè)應(yīng)答響應(yīng)。

8. 主節(jié)點(diǎn)收到一個(gè)復(fù)制組中大多數(shù)節(jié)點(diǎn)的成功返回后，主節(jié)點(diǎn)通過SPDK將寫請(qǐng)求應(yīng)用到數(shù)據(jù)塊上。

9. 隨后，主節(jié)點(diǎn)通過RDMA向PolarSwitch返回。

10. PolarSwitch標(biāo)記請(qǐng)求成功并通知上層的POLARDB。

數(shù)據(jù)副本一致性模型

ParallelRaft協(xié)議設(shè)計(jì)動(dòng)機(jī)

一個(gè)產(chǎn)品級(jí)別的分布式存儲(chǔ)系統(tǒng)需要確保所有提交的修改在各種邊界情況下均不丟失。PolarFS在Chunk層面引入一致性協(xié)議來保證文件系統(tǒng)數(shù)據(jù)的可靠性和一致性。設(shè)計(jì)之初，從工程實(shí)現(xiàn)的成熟度考慮，我們選擇了Raft算法，但對(duì)于我們構(gòu)建的超低延遲的高并發(fā)存儲(chǔ)系統(tǒng)而言，很快就遇到了一些坑。

Raft為了簡(jiǎn)單性和協(xié)議的可理解性，采用了高度串行化的設(shè)計(jì)。日志在leader和follower上都不允許有空洞，其意味著所有l(wèi)og項(xiàng)會(huì)按照順序被follower確認(rèn)、被leader提交并apply到所有副本上。因此當(dāng)有大量并發(fā)寫請(qǐng)求執(zhí)行時(shí)，會(huì)按順序依次提交。處于隊(duì)列尾部的請(qǐng)求，必需等待所有之前的請(qǐng)求已被持久化到硬盤并返回后才會(huì)被提交和返回，這增加了平均延遲也降低了吞吐量。我們發(fā)現(xiàn)當(dāng)并發(fā)I／O深度從8升到32時(shí)，I／O吞吐量會(huì)降低一半。

Raft并不十分適用于多連接的在高并發(fā)環(huán)境。實(shí)際中l(wèi)eader和follower使用多條連接來傳送日志很常見。當(dāng)一個(gè)鏈接阻塞或者變慢，log項(xiàng)到達(dá)follower的順序就會(huì)變亂，也即是說，一些次序靠后的log項(xiàng)會(huì)比次序靠前的log項(xiàng)先到。但是，Raft的follower必需按次序接收log項(xiàng)，這就意味著這些log項(xiàng)即使被記錄到硬盤也只能等到前面所有缺失的log項(xiàng)到達(dá)后才能返回。并且假如大多數(shù)follower都因一些缺失的項(xiàng)被阻塞時(shí)，leader也會(huì)出現(xiàn)卡頓。我們希望有一個(gè)更好的協(xié)議可以適應(yīng)這樣的情形。

由于PolarFS之上運(yùn)行的是Database事務(wù)處理系統(tǒng)，它們?cè)跀?shù)據(jù)庫(kù)邏輯層面的并行控制算法使得事務(wù)可以交錯(cuò)或亂序執(zhí)行的同時(shí)還能生成可串行化的結(jié)果。這些應(yīng)用天然就需要容忍標(biāo)準(zhǔn)存儲(chǔ)語(yǔ)義可能出現(xiàn)的I／O亂序完成情況，并由應(yīng)用自身進(jìn)一步保證數(shù)據(jù)一致性。因此我們可以利用這一特點(diǎn)，在PolarFS中依照存儲(chǔ)語(yǔ)義放開Raft一致性協(xié)議的某些約束，從而獲得一種更適合高I／O并發(fā)能力發(fā)揮的一致性協(xié)議。

我們?cè)赗aft的基礎(chǔ)上，提供了一種改進(jìn)型的一致性協(xié)議ParallelRaft。ParallelRaft的結(jié)構(gòu)與Raft一致，只是放開了其嚴(yán)格有序化的約束。

亂序日志復(fù)制

Raft通過兩個(gè)方面保障串行化：

1. 當(dāng)leader發(fā)送一個(gè)log項(xiàng)給follower，follower需要返回ack來確認(rèn)該log項(xiàng)已經(jīng)被收到且記錄，同時(shí)也隱式地表明所有之前的log項(xiàng)均已收到且保存完畢。

2. 當(dāng)leader提交一個(gè)log項(xiàng)并廣播至所有follower，它也同時(shí)確認(rèn)了所有之前的log項(xiàng)都已被提交了。ParallelRaft打破了這兩個(gè)限制，并讓這些步驟可亂序執(zhí)行。

因此，ParallelRaft與Raft最根本的不同在于，當(dāng)某個(gè)entry提交成功時(shí)，并不意味著之前的所有entry都已成功提交。因此我們需要保證：

1. 在這種情況下，單個(gè)存儲(chǔ)的狀態(tài)不會(huì)違反存儲(chǔ)語(yǔ)義的正確性；

2. 所有已提交的entry在各種邊界情況下均不會(huì)丟失；

有了這兩點(diǎn)，結(jié)合數(shù)據(jù)庫(kù)或其他應(yīng)用普遍存在的對(duì)存儲(chǔ)I／O亂序完成的默認(rèn)容忍能力，就可以保證它們?cè)赑olarFS上的正常運(yùn)轉(zhuǎn)，并獲得PolarFS提供的數(shù)據(jù)可靠性。

ParallelRaft的亂序執(zhí)行遵循如下原則：

1. 當(dāng)寫入的Log項(xiàng)彼此的存儲(chǔ)范圍沒有交疊，那么就認(rèn)為L(zhǎng)og項(xiàng)無沖突可以亂序執(zhí)行；

2. 否則，沖突的Log項(xiàng)將按照寫入次序依次完成。

容易知道，依照此原則完成的I／O不會(huì)違反傳統(tǒng)存儲(chǔ)語(yǔ)義的正確性。
接下來我們來看log的ack-commit-apply環(huán)節(jié)是如何因此得到優(yōu)化并且保持一致性的。

• 亂序確認(rèn)（ack）：當(dāng)收到來自leader的一個(gè)log項(xiàng)后，Raft follower會(huì)在它及其所有之前的log項(xiàng)都持久化后，才發(fā)送ack。ParallelRaft則不同，任何log entry成功持久化后均能立即返回，這樣就優(yōu)化了系統(tǒng)的平均延遲。

• 亂序提交（commit）：Raft leader串行提交log項(xiàng)，一個(gè)log項(xiàng)只有之前的所有項(xiàng)提交之后才能提交。而ParallelRaft的leader在一個(gè)log項(xiàng)的多數(shù)副本已經(jīng)確認(rèn)之后即可提交。這符合存儲(chǔ)系統(tǒng)的語(yǔ)義，例如，NVMe SSD驅(qū)動(dòng)并不檢查讀寫命令的LBA來保證并行命令的次序，對(duì)命令的完成次序也沒有任何保證。

• 亂序應(yīng)用（apply）：對(duì)于Raft，所有l(wèi)og項(xiàng)都按嚴(yán)格的次序apply，因此所有副本的數(shù)據(jù)文件都是一致的。但是，ParallelRaft由于亂序的確認(rèn)和提交，各副本的log都可能在不同位置出現(xiàn)空洞，這里的挑戰(zhàn)是，如何保證前面log項(xiàng)有缺失時(shí)，安全地apply一個(gè)log項(xiàng)？

ParallelRaft引入了一種新型的數(shù)據(jù)結(jié)構(gòu)look behind buffer來解決apply中的問題。

1. ParallelRaft的每個(gè)log項(xiàng)都附帶有一個(gè)look behind buffer。look behind buffer存放了前N個(gè)log項(xiàng)修改的LBA摘要信息。

2. look behind buffer的作用就像log空洞上架設(shè)的橋梁，N表示橋梁的寬度，也就是允許單個(gè)空洞的大長(zhǎng)度，N的具體取值可根據(jù)網(wǎng)絡(luò)連續(xù)缺失log項(xiàng)的概率大小，靜態(tài)地調(diào)整為合適的值，以保證log橋梁的連續(xù)性。

3. 通過look behind buffer，follower能夠知道一個(gè)log項(xiàng)是否沖突，也就是說是否有缺失的前序log項(xiàng)修改了范圍重疊的LBAs。沒有沖突的log項(xiàng)能被安全apply。如有沖突，它們會(huì)被加到一個(gè)pending list，待之前缺失的沖突log項(xiàng)apply之后，才會(huì)接著apply。

通過上述的異步ack、異步commit和異步apply，PolarFS的chunk log entry的寫入和提交避免了次序造成的額外等待時(shí)間，從而有效縮減了高并發(fā)3副本寫的平均時(shí)延。

ParallelRaft協(xié)議正確性

我們?cè)赑arallelRaft的設(shè)計(jì)中，確保了Raft協(xié)議關(guān)鍵特性不丟失，從而保障了新協(xié)議的正確性。

1. ParallelRaft協(xié)議的設(shè)計(jì)繼承了原有Raft協(xié)議的Election Safety、 Leader Append-Only及Log Matching 特性。

2. 沖突log會(huì)以嚴(yán)格的次序提交，因此協(xié)議的State Machine Safety特性能夠最終得以保證。

3. 我們?cè)贚eader選舉階段額外引入了一個(gè)Merge階段，填補(bǔ)Leader中l(wèi)og的空洞，能夠有效保障協(xié)議的Leader Completeness特性。

PolarFS中與POLARDB緊密相關(guān)的設(shè)計(jì)

文件系統(tǒng)多副本高速寫入——數(shù)據(jù)庫(kù)單實(shí)例的超高TPS，數(shù)據(jù)高可靠

PolarFS設(shè)計(jì)中采用了如下技術(shù)以充分發(fā)揮I/O性能：

1. PolarFS采用了綁定CPU的單線程有限狀態(tài)機(jī)的方式處理I/O，避免了多線程I/O pipeline方式的上下文切換開銷。

2. PolarFS優(yōu)化了內(nèi)存的分配，采用MemoryPool減少內(nèi)存對(duì)象構(gòu)造和析構(gòu)的開銷，采用巨頁(yè)來降低分頁(yè)和TLB更新的開銷。

3. PolarFS通過中心加局部自治的結(jié)構(gòu)，所有元數(shù)據(jù)均緩存在系統(tǒng)各部件的內(nèi)存中，基本完全避免了額外的元數(shù)據(jù)I/O。

4. PolarFS采用了全用戶空間I/O棧，包括RDMA和SPDK，避免了內(nèi)核網(wǎng)絡(luò)棧和存儲(chǔ)棧的開銷。

在相同硬件環(huán)境下的對(duì)比測(cè)試，PolarFS中數(shù)據(jù)塊3副本寫入性能接近于單副本本地SSD的延遲性能。從而在保障數(shù)據(jù)可靠性的同時(shí)，極大地提升POLARDB的單實(shí)例TPS性能。

下圖是我們采用Sysbench對(duì)不同負(fù)載進(jìn)行的初步測(cè)試比較。

1. POLARDB on PolarFS

2. Alibaba MySQL Cloud Service RDS

用例負(fù)載：OLTP，只讀、只寫（update : delete : insert = 2:1:1）、讀寫混合（read : write = 7:2）。數(shù)據(jù)庫(kù)測(cè)試集數(shù)據(jù)量為500GB。

可以發(fā)現(xiàn)POLARDB在PolarFS下取得了較好的性能，PolarFS同時(shí)支持了POLARDB的高TPS和數(shù)據(jù)的高可靠性。

文件系統(tǒng)共享訪問——寫多讀的數(shù)據(jù)庫(kù)QPS強(qiáng)擴(kuò)展，數(shù)據(jù)庫(kù)實(shí)例的Failover

PolarFS是共享訪問的分布式文件系統(tǒng)，每個(gè)文件系統(tǒng)實(shí)例都有相應(yīng)的Journal文件和與之對(duì)應(yīng)的Paxos文件。Journal文件記錄了metadata的修改歷史，是共享實(shí)例之間元數(shù)據(jù)同步的中心。Journal文件邏輯上是一個(gè)固定大小的循環(huán)buffer。PolarFS會(huì)根據(jù)水位來回收journal。Paxos文件基于Disk Paxos實(shí)現(xiàn)了分布式互斥鎖。

由于journal對(duì)于PolarFS非常關(guān)鍵，它們的修改必需被Paxos互斥鎖保護(hù)。如果一個(gè)節(jié)點(diǎn)希望在journal中追加項(xiàng)，其必需使用DiskPaxos算法來獲取Paxos文件中的鎖。通常，鎖的使用者會(huì)在記錄持久化后馬上釋放鎖。但是一些故障情況下使用者不釋放鎖。為此在Paxos互斥鎖上分配有一個(gè)租約lease。其他競(jìng)爭(zhēng)者可以重啟競(jìng)爭(zhēng)過程。當(dāng)PolarFS當(dāng)節(jié)點(diǎn)開始同步其他節(jié)點(diǎn)修改的元數(shù)據(jù)時(shí)，它從上次掃描的位置掃描到j(luò)ournal末尾，將新entry更新到memory cache中。

下圖展示了文件系統(tǒng)元數(shù)據(jù)更新和同步的過程。

1. 節(jié)點(diǎn)1分配塊201至文件316后，請(qǐng)求互斥鎖，并獲得。

2. Node 1開始記錄事務(wù)至journal中。最后寫入項(xiàng)標(biāo)記為pending tail。當(dāng)所有的項(xiàng)記錄之后，pending tail變成journal的有效tail。

3. Node1更新superblock，記錄修改的元數(shù)據(jù)。與此同時(shí)，node2嘗試獲取node1擁有的互斥鎖，Node2會(huì)失敗重試。

4. Node2在Node1釋放lock后拿到鎖，但journal中node1追加的新項(xiàng)決定了node2的本地元數(shù)據(jù)是過時(shí)的。

5. Node2掃描新項(xiàng)后釋放lock。然后node2回滾未記錄的事務(wù)并更新本地metadata。最后Node2進(jìn)行事務(wù)重試。

6. Node3開始自動(dòng)同步元數(shù)據(jù)，它只需要load增量項(xiàng)并在它本地重放即可。

PolarFS的上述共享機(jī)制非常適合POLARDB一寫多讀的典型應(yīng)用擴(kuò)展模式。一寫多讀模式下沒有鎖爭(zhēng)用開銷，只讀實(shí)例可以通過原子I/O無鎖獲取Journal信息，從而使得POLARDB可以提供近線性的QPS性能擴(kuò)展。

由于PolarFS支持了基本的多寫一致性保障，當(dāng)可寫實(shí)例出現(xiàn)故障時(shí)，POLARDB能夠方便地將只讀實(shí)例升級(jí)為可寫實(shí)例，而不必?fù)?dān)心底層存儲(chǔ)產(chǎn)生不一致問題，因而方便地提供了數(shù)據(jù)庫(kù)實(shí)例Failover的功能。

文件系統(tǒng)級(jí)快照——POLARDB的瞬時(shí)邏輯備份

對(duì)于百TB級(jí)超大數(shù)據(jù)庫(kù)實(shí)例的備份而言，數(shù)據(jù)庫(kù)快照是必須支持的功能。

PolarFS采用了自有的專利快照技術(shù)，能夠基于位于底層的多個(gè)ChunkServer的局部快照，構(gòu)建Volume上的統(tǒng)一的文件系統(tǒng)即時(shí)映像。POLARDB利用自身數(shù)據(jù)庫(kù)的日志，能夠基于此文件系統(tǒng)映像快速構(gòu)建出此具體時(shí)點(diǎn)的數(shù)據(jù)庫(kù)快照，從而有效支持?jǐn)?shù)據(jù)庫(kù)備份和數(shù)據(jù)分析的需求。

可以發(fā)現(xiàn)，POLARDB的高性能、強(qiáng)擴(kuò)展、輕運(yùn)維等具備競(jìng)爭(zhēng)優(yōu)勢(shì)的優(yōu)異特性，與PolarFS的緊密協(xié)作息息相關(guān)，PolarFS發(fā)揮了強(qiáng)大的使能作用。

結(jié)論

PolarFS是一個(gè)專為云數(shù)據(jù)庫(kù)而設(shè)計(jì)的分布式文件系統(tǒng)，其能夠支持跨節(jié)點(diǎn)高可靠性同時(shí)提供極致的性能。PolarFS采用了新興硬件和先進(jìn)的優(yōu)化技術(shù)，例如OS-bypass和zero-copy，使得PolarFS中數(shù)據(jù)塊3副本寫入性能接近于單副本本地SSD的延遲性能。PolarFS在用戶空間實(shí)現(xiàn)了POSIX兼容接口，使得POLARDB等數(shù)據(jù)庫(kù)服務(wù)能夠盡量少地修改即可獲得PolarFS帶來的高性能的優(yōu)勢(shì)。

可以看到，面向數(shù)據(jù)庫(kù)的專有文件系統(tǒng)，是保障未來數(shù)據(jù)庫(kù)技術(shù)領(lǐng)先的一個(gè)不可或缺的關(guān)鍵一環(huán)。數(shù)據(jù)庫(kù)內(nèi)核技術(shù)的進(jìn)展及其專有文件系統(tǒng)的使能，是一個(gè)相輔相成的演進(jìn)過程，二者的結(jié)合也會(huì)隨著當(dāng)今系統(tǒng)技術(shù)的進(jìn)步而愈加緊密。

未來我們將探索NVM和FPGA等新硬件，以期通過文件系統(tǒng)與數(shù)據(jù)庫(kù)的深度結(jié)合來進(jìn)一步優(yōu)化POLARDB數(shù)據(jù)庫(kù)的性能。

作者：鳴嵩，弘然，明書，旭危，寧進(jìn)，文義，韓逸，翊云

本文標(biāo)題：面向云數(shù)據(jù)庫(kù)，超低延遲文件系統(tǒng)PolarFS誕生了-創(chuàng)新互聯(lián)
網(wǎng)站地址：http://muchs.cn/article16/dhdjgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、商城網(wǎng)站、服務(wù)器托管、做網(wǎng)站、小程序開發(fā)、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)