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

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

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

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

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

背景

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

設(shè)計初衷

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

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

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

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

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

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

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

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

系統(tǒng)組件

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

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

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

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

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

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

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

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

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

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

Volume

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

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

Chunk

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

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

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

Block

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

下面我們詳細(xì)介紹PolarFS的各個系統(tǒng)組件。

libpfs

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

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

PolarSwitch

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

ChunkServer

ChunkServer部署在后端存儲節(jié)點上。一個存儲節(jié)點可以有多個ChunkServer。每個ChunkServer綁定到一個CPU核，并管理一個獨立的NVMe SSD盤，因此ChunkServer之間沒有資源爭搶。

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

ChunkServer會復(fù)制寫請求到對應(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ù)信息維護；

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

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

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

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

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

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

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

PolarCtrl服務(wù)由于不直接處理高并發(fā)的I／O流，其狀態(tài)更新頻率相對較低，因而可采用典型的多節(jié)點高可用架構(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 流程

下面我們通過一個I/O的處理來說明各組件的互動過程。

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

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

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

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

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

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

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

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

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

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

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

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

ParallelRaft協(xié)議設(shè)計動機

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

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

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

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

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

亂序日志復(fù)制

Raft通過兩個方面保障串行化：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ParallelRaft協(xié)議正確性

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

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

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

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

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

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

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

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

2. PolarFS優(yōu)化了內(nèi)存的分配，采用MemoryPool減少內(nèi)存對象構(gòu)造和析構(gòu)的開銷，采用巨頁來降低分頁和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ò)棧和存儲棧的開銷。

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

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

1. POLARDB on PolarFS

2. Alibaba MySQL Cloud Service RDS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)論

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

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

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