作者：我是程序員 阿里云云棲社區(qū)技術(shù)文章

本文通過描述關(guān)系型數(shù)據(jù)庫發(fā)展的背景以及云計算的時代特征，分享了數(shù)據(jù)庫計算力的螺旋式上升的進化理念。并且結(jié)合阿里云 RDS 產(chǎn)品的發(fā)展路徑，闡述了自主研發(fā)的新一代云托管關(guān)系型數(shù)據(jù)庫 PolarDB 的產(chǎn)品整體設(shè)計思想，同時也對一些關(guān)鍵技術(shù)點進行了解讀。

1. 背景

關(guān)系型數(shù)據(jù)庫

談到關(guān)系型數(shù)據(jù)庫，在這個知識日新月異的TMT時代，聽起來有些古董，這個起源于半個世紀以前的IT技術(shù)，事實上一直處于現(xiàn)代社會科技的核心，支撐著當(dāng)今世界絕大多數(shù)的商業(yè)科技文明。CPU、操作系統(tǒng)、數(shù)據(jù)庫這三大核心領(lǐng)域，基本上就是IT時代的縮影，同時也是一切信息化處理、計算力和智能化的基石。從1970年E.F.Codd發(fā)表了一篇里程碑論文A Relational Model of Data for Large Shared Data Banks，到80年代初期支持SQL的商用關(guān)系型數(shù)據(jù)庫DB2，Oracle的面市，以及90年代初SQL-Server的誕生，都是關(guān)系型數(shù)據(jù)庫成功的代表。

時至今日，隨著全球互聯(lián)網(wǎng)的發(fā)展，大數(shù)據(jù)技術(shù)的廣泛應(yīng)用，涌現(xiàn)出越來越多的新型數(shù)據(jù)庫，然而關(guān)系型數(shù)據(jù)庫仍然占據(jù)主導(dǎo)地位。最主要的原因之一就是關(guān)系型數(shù)據(jù)庫采用了SQL標準，這種高級的非過程化編程接口語言，將計算機科學(xué)和易于人類理解認知的數(shù)據(jù)管理方式完美的銜接在了一起，目前還難以超越。

SQL語言

SQL(Structured Query Language)語言是1974年由Boyce和Chamberlin提出的一種介于關(guān)系代數(shù)與關(guān)系演算之間的結(jié)構(gòu)化查詢語言，其本質(zhì)是用一種類似于自然語言的關(guān)鍵字和語法來定義和操作數(shù)據(jù)，進行可編程的數(shù)據(jù)存儲、查詢以及管理。這種抽象編程接口，將具體的數(shù)據(jù)問題與數(shù)據(jù)的存放、查詢實現(xiàn)的細節(jié)解耦開來，使得商業(yè)業(yè)務(wù)邏輯以及信息管理的計算模式能夠被大量復(fù)制和應(yīng)用，解放了生產(chǎn)力，也極大的促進了商業(yè)化關(guān)系型數(shù)據(jù)庫自身的發(fā)展。從SQL后來不斷發(fā)展和豐富來看，SQL已經(jīng)成為關(guān)系型數(shù)據(jù)庫語言的標準和王者。到今天這種編程語言還沒有更加完美的替代品。

OLTP

1976年，Jim Gray發(fā)表了名為"Granularity of Locks and Degrees of Consistency in a Shared DataBase"的論文，正式定義了數(shù)據(jù)庫事務(wù)的概念和數(shù)據(jù)一致性的機制。而OLTP是關(guān)系型數(shù)據(jù)庫涉及事務(wù)處理的典型應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。事務(wù)處理需要遵循ACID四個要素來保證數(shù)據(jù)的正確性，包括原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）。而衡量OLTP處理能力的性能指標主要有響應(yīng)時間、吞吐率等。

開源數(shù)據(jù)庫生態(tài)

在我們簡要的回顧了關(guān)系型數(shù)據(jù)庫的歷史、地位和發(fā)展階段后，我們不難看到Oracle、SQL-Server、DB2等關(guān)系型數(shù)據(jù)庫仍然占據(jù)著全球商業(yè)數(shù)據(jù)庫的主導(dǎo)地位，雖然曾經(jīng)耳熟能詳?shù)腎nformix、Sybase已經(jīng)淡出大眾的視線。然而，從20世紀90年代開始，另一股推崇知識分享、自由開放的軟件精神成為趨勢和潮流，尤其以Linux、MySQL、PostgreSQL等為代表的開源軟件，開始以強大的生命力不斷發(fā)展壯大，釋放出巨大的社會進步力量，這些被自由分享的科技紅利，孕育和促進了全球互聯(lián)網(wǎng)高科技公司的飛速發(fā)展。這是整個人類社會的進步，我們要感謝那些開源軟件的斗士們，Richard Stallman，Linus Torvalds，Michael Widenius等。當(dāng)然，最近幾年國內(nèi)涌現(xiàn)出越來越多積極參與到開源主流社區(qū)的中國公司，也在不斷地將技術(shù)分享回饋給開源世界。

根據(jù)DB-engines網(wǎng)站的最新統(tǒng)計，不難發(fā)現(xiàn)，當(dāng)把開源數(shù)據(jù)庫MySQL和PostgreSQL加在一起，開源數(shù)據(jù)庫就已經(jīng)超越了商業(yè)數(shù)據(jù)庫Oracle，成為世界上最流行的關(guān)系型數(shù)據(jù)庫。

2. 云計算當(dāng)前的階段

如果說關(guān)系型數(shù)據(jù)庫是IT時代的產(chǎn)物。那么在互聯(lián)網(wǎng)時代的云計算，關(guān)系型數(shù)據(jù)庫目前正處于一個什么階段呢？IT時代從某種程度上講，更多是創(chuàng)造了計算力，那么進入互聯(lián)網(wǎng)時代的云計算，則是專注于用戶和計算力的連接，提供無處不在的計算力，這個其實是云計算商業(yè)模式的成功所在，可以稱之為1.0版本。而云計算2.0版本，需要在云環(huán)境下，重新進化和升級計算力，這種進化體現(xiàn)了社會計算力的整合以及計算資源能效的進步。為了順應(yīng)綠色計算以及共享經(jīng)濟的發(fā)展潮流，不僅僅需要云服務(wù)器，云數(shù)據(jù)庫，網(wǎng)絡(luò)互聯(lián)，硬件芯片等等各個軟硬件系統(tǒng)領(lǐng)域的融合以及演進升級，還需要堅持科技以需求為本、服務(wù)以用戶為根的科技普惠大眾的理念來進一步促進計算效率和計算智能的提高。

我們正處在一個蓬勃發(fā)展的云計算2.0階段。在這個階段，關(guān)系型數(shù)據(jù)庫在云托管環(huán)境逐漸暴露出一些問題，作為在云計算時代的先行者，Amazon于2014年11月12日 的AWS re:Invent 2014大會，發(fā)布Aurora云托管關(guān)系型數(shù)據(jù)庫就是為了解決這些問題。這個新一代的數(shù)據(jù)庫的發(fā)布，也昭示著云計算時代，傳統(tǒng)的IT技術(shù)核心產(chǎn)品將揭開自我進化的序幕。而2017年SIGMOD數(shù)據(jù)大會， Amazon 發(fā)布了論文Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases,更加開放的解釋了基于云環(huán)境的Cloud-Native設(shè)計的關(guān)系型數(shù)據(jù)庫是如何應(yīng)孕而生的。

3. 為什么阿里云要研發(fā)新一代的關(guān)系型數(shù)據(jù)庫PolarDB ?

在我們回顧了關(guān)系型數(shù)據(jù)庫以及云計算的背景之后，我們不難發(fā)現(xiàn), 云計算1.0雖然解決了用戶和計算的連接的問題，但是還需要進一步解決在一個共享計算的環(huán)境下，傳統(tǒng)關(guān)系型數(shù)據(jù)庫和公有云服務(wù)環(huán)境的融合問題。

云計算1.0用低廉的成本，靈活快速的部署、彈性和擴展能力，獲得了傳統(tǒng)IT計算上云的轉(zhuǎn)換動力。在低成本享受普惠科技成為常態(tài)之后，隨著用戶業(yè)務(wù)的增長，用戶新的痛點開始出現(xiàn)，例如，如何從根本上解決用持續(xù)低的成本，享受和傳統(tǒng)IT計算力一樣，甚至更好的云服務(wù)，成為迫切需要。這初看起來像偽命題，仔細分析之后，卻淋漓盡致的體現(xiàn)了螺旋式上升的哲學(xué)思想。就好像在PC服務(wù)器涌現(xiàn)的時代，PC服務(wù)器首先用低廉的價格提供了和小型服務(wù)器接近的計算能力，然后在保持成本和性價比優(yōu)勢的基礎(chǔ)上，實現(xiàn)了超越小型服務(wù)器的性能優(yōu)勢，直至終結(jié)了小型服務(wù)器時代，開始了PC服務(wù)器時代。

所以說云計算時代還遠遠沒有到達鼎盛時期，除非它通過自身進化演變，在不斷保持性價比優(yōu)勢的同時，在具有快速靈活彈性的內(nèi)在屬性基礎(chǔ)上，擁有超過傳統(tǒng)IT計算力的能力之后，云計算才會真正進入它所主宰的時代，這只是個時間問題。

也就是說今天不只是阿里云要做這樣一款關(guān)系型數(shù)據(jù)庫，而是所有的云計算廠商都不可避免的要經(jīng)歷這樣一個階段。那就是云計算時代傳統(tǒng)IT計算力的重建和進化！只不過Amazon走在了最前面，而阿里云緊跟其后，都需要經(jīng)歷這進化到蛻變的過程。在這個過程中，新一代關(guān)系型數(shù)據(jù)庫是關(guān)鍵的里程碑之一。同理，接下來應(yīng)該有更多更加高級的云服務(wù)，比如智能云操作系統(tǒng)出現(xiàn)，來融合為云時代設(shè)計的硬件芯片和網(wǎng)絡(luò)互聯(lián)等等。

在IT時代，傳統(tǒng)的計算力（例如用關(guān)系型數(shù)據(jù)庫來處理結(jié)構(gòu)化數(shù)據(jù)等）是服務(wù)于系統(tǒng)硬件隔離環(huán)境下的多用戶使用場景的。而云計算時代是多客戶Self-Service租用環(huán)境，各種計算負載場景更加復(fù)雜，在這種計算負載變遷的環(huán)境下，如何解決IT時代的技術(shù)產(chǎn)物和云計算時代應(yīng)用環(huán)境的適配矛盾，正是云計算自我進化的內(nèi)在推動力。

例如，在公有云環(huán)境下，隨著用戶的增多，以及用戶業(yè)務(wù)和數(shù)據(jù)的增長，備份、性能、遷移、升級、只讀實例、磁盤容量、Binlog延遲等相關(guān)問題漸漸顯現(xiàn)出來。這背后大部分原因是由于I/O瓶頸（存儲和網(wǎng)絡(luò)）導(dǎo)致，亟須通過技術(shù)革新以及新的產(chǎn)品架構(gòu)解決這個問題。另一方面，從產(chǎn)品形態(tài)來講，阿里云RDS目前的產(chǎn)品形態(tài)各具優(yōu)勢，在下一節(jié)會詳細介紹。但是從產(chǎn)品架構(gòu)的發(fā)展來看，除去數(shù)據(jù)庫存儲引擎的類型之外，對于關(guān)系型數(shù)據(jù)庫，考慮到工程效率以及運維成本，最好有一種通用的產(chǎn)品技術(shù)架構(gòu)能兼顧不同用戶場景的需求，而不是針對每一個場景都實現(xiàn)一種對應(yīng)的技術(shù)架構(gòu)。

在接下來的內(nèi)容，通過講述阿里云RDS的不同產(chǎn)品形態(tài)的特點，我們會更加清晰的了解到，PolarDB的產(chǎn)品形態(tài)正是在吸收了之前幾種產(chǎn)品形態(tài)的優(yōu)點而孕育而生的。

4. PolarDB的設(shè)計思想

用戶需求和公有云自身發(fā)展的選擇

作為云托管的關(guān)系型數(shù)據(jù)，除了關(guān)系型數(shù)據(jù)庫的核心特征之外。PoalrDB更多的關(guān)注于如何提供滿足用戶業(yè)務(wù)需求的云服務(wù)，并且通過技術(shù)革新，不斷進化，在提供更好的數(shù)據(jù)庫計算力的同時，滿足用戶的如下業(yè)務(wù)需求：

上云成本

OLTP性能

業(yè)務(wù)連續(xù)性

在線業(yè)務(wù)擴展

數(shù)據(jù)安全

另一方面云計算除了成本優(yōu)勢之外，彈性和可擴展性也是云計算的天然屬性。為了用戶業(yè)務(wù)的擴展，更好的Scale Up以及故障恢復(fù)，計算和存儲分離的架構(gòu)成為云資源環(huán)境更好的選擇。這一點將在下一節(jié)RDS產(chǎn)品架構(gòu)的演進中得到進一步的詮釋。

阿里云RDS產(chǎn)品架構(gòu)的演進

如上所述，阿里云PolarDB和Amazon Aurora數(shù)據(jù)庫進化的方向是一致的，然而進化的路徑各有不同。本身來講，這是由于各自的數(shù)據(jù)庫云服務(wù)實現(xiàn)方式不同所決定的。阿里云RDS MySQL有如下幾個版本。這些產(chǎn)品形態(tài)滿足不同的用戶業(yè)務(wù)場景，具有不同的特點，可以進行優(yōu)勢互補。

1. MySQL基礎(chǔ)版

MySQL基礎(chǔ)版采用數(shù)據(jù)庫計算節(jié)點和存儲節(jié)點分離的方式，利用云盤數(shù)據(jù)本身的可靠性和多副本的特性，同時也利用了ECS云服務(wù)器虛擬化來提升標準化部署、版本和運維的管理效率，能夠滿足低端用戶不太注重高可用服務(wù)的業(yè)務(wù)場景。同時這種架構(gòu)對于數(shù)據(jù)庫的遷移，數(shù)據(jù)容量的擴容，計算節(jié)點的Scale Up，計算節(jié)點故障恢復(fù)都有天然的優(yōu)勢，根本原因就是計算和存儲的分離。后面也會講到，PolarDB也采用了存儲和計算分離的設(shè)計理念。

2. MySQL高可用版

MySQL高可用版則是針對企業(yè)級用戶提供的高可用數(shù)據(jù)庫版本，提供99.95%的SLA保障。采用Active-Standby的高可用架構(gòu)，主節(jié)點和備節(jié)點之間通過MySQL Binlog進行數(shù)據(jù)的Replication。當(dāng)主節(jié)點發(fā)生故障，備節(jié)點接管服務(wù)。同時還支持多個只讀節(jié)點，支持負載均衡的數(shù)據(jù)讀寫分離的訪問方式。采用Shared-Nothing架構(gòu)，計算和數(shù)據(jù)位于同一個節(jié)點，最大程度保障性能的同時又通過數(shù)據(jù)的多副本帶來可靠性。

3. MySQL金融版

MySQL金融版可以說是針對金融行業(yè)等高端用戶設(shè)計的高可用、高可靠云服務(wù)產(chǎn)品，采用分布式Raft協(xié)議來保證數(shù)據(jù)的強一致性，擁有更加優(yōu)異的故障恢復(fù)時間，更加滿足數(shù)據(jù)容災(zāi)備份等業(yè)務(wù)場景的需求。

PolarDB的進化

PolarDB采用存儲與計算分離的技術(shù)架構(gòu)，同時可以支持更多的只讀節(jié)點。主節(jié)點和只讀節(jié)點之間是Active-Active的Failover方式，計算節(jié)點資源得到充分利用，由于使用共享存儲，共享同一份數(shù)據(jù)，進一步降低了用戶的使用成本。下一節(jié)我們將進一步從細節(jié)上描述PolarDB的關(guān)鍵特性。

PolarDB的設(shè)計思想有幾個大的革新。一是通過重新設(shè)計特定的文件系統(tǒng)來存取Redo log這種特定的WAL I/O數(shù)據(jù)，二是通過高速網(wǎng)絡(luò)和高效協(xié)議將數(shù)據(jù)庫文件和Redo log文件放在共享存儲設(shè)備上，避免了多次長路徑I/O的重復(fù)操作，相比較Binlog這種方式更加巧妙。另外在DB Server設(shè)計上，采用MySQL完全兼容的思路，完全擁抱開源生態(tài)，從SQL的編譯、性能優(yōu)化器和執(zhí)行計劃等等都保留了傳統(tǒng)關(guān)系型數(shù)據(jù)庫的特色。并且針對Redolog的I/O路徑，專門設(shè)計了多副本共享存儲塊設(shè)備。

我們知道，分布式數(shù)據(jù)庫一直是數(shù)據(jù)庫領(lǐng)域的熱點，具有非常大的實現(xiàn)難度。不管是遵循CAP理論，還是BASE思想，通用的分布式關(guān)系型數(shù)據(jù)庫基本上很難做到技術(shù)和商用的完美平衡。與SQL標準以及主流數(shù)據(jù)庫兼容，OLTP ACID事務(wù)100%支持，99.99%的高可用，高性能低延遲并發(fā)處理能力，彈性Scale Up，Scale out可擴展性，備份容災(zāi)和低成本遷移等等，能夠完美兼顧所有這些特點的商用關(guān)系型數(shù)據(jù)庫還沒有出現(xiàn)。

阿里云PolarDB和Amazon Aurora的一個共同設(shè)計哲學(xué)就是，放棄了通用分布式數(shù)據(jù)庫OLTP多路并發(fā)寫的支持，采用一寫多讀的架構(gòu)設(shè)計，簡化了分布式系統(tǒng)難以兼顧的理論模型，又能滿足絕大多數(shù)OLTP的應(yīng)用場景和性能要求?？傊?，100% MySQL的兼容性，加上專用的文件系統(tǒng)和共享存儲塊設(shè)備設(shè)計，以及在下文中提到的多項高級技術(shù)的應(yīng)用，使得新一代關(guān)系型數(shù)據(jù)庫PoalrDB在云時代必將大放異彩。

5. PolarDB產(chǎn)品關(guān)鍵技術(shù)點剖析

在講述了阿里云RDS的不同產(chǎn)品形態(tài)之后，我們再從整體上看一看PolarDB的產(chǎn)品架構(gòu)。下圖勾畫了PolarDB產(chǎn)品的主要模塊，包括數(shù)據(jù)庫服務(wù)器，文件系統(tǒng)，共享塊存儲等。

PoalrDB產(chǎn)品架構(gòu)

（阿里云關(guān)系型數(shù)據(jù)庫PoalrDB集群）

如圖所示，PolarDB產(chǎn)品是一個分布式集群架構(gòu)的設(shè)計。它集眾多高級的技術(shù)實現(xiàn)于一身，使得數(shù)據(jù)庫OLTP處理性能有了質(zhì)的飛躍。PoalrDB采用了存儲與計算分離的設(shè)計理念，滿足公有云計算環(huán)境下用戶業(yè)務(wù)彈性擴展的剛性需求。數(shù)據(jù)庫計算節(jié)點和存儲節(jié)點之間采用高速網(wǎng)絡(luò)互聯(lián)，并通過RDMA協(xié)議進行數(shù)據(jù)傳輸，使得I/O性能不在成為瓶頸。

數(shù)據(jù)庫節(jié)點采用和MySQL完全兼容的設(shè)計。主節(jié)點和只讀節(jié)點之間采用Active-Active的Failover方式，提供DB的高可用服務(wù)。DB的數(shù)據(jù)文件、redolog等通過User-Space用戶態(tài)文件系統(tǒng)，經(jīng)過塊設(shè)備數(shù)據(jù)管理路由，依靠高速網(wǎng)絡(luò)和RDMA協(xié)議傳輸?shù)竭h端的Chunk Server。同時DB Server之間僅需同步Redo log相關(guān)的元數(shù)據(jù)信息。Chunk Server的數(shù)據(jù)采用多副本確保數(shù)據(jù)的可靠性，并通過Parallel-Raft協(xié)議保證數(shù)據(jù)的一致性。

在描述了PolarDB的產(chǎn)品架構(gòu)之后，我們再分別從分布式架構(gòu)，數(shù)據(jù)庫高可用，網(wǎng)絡(luò)協(xié)議，存儲塊設(shè)備，文件系統(tǒng)和虛擬化等方面逐一介紹下PolarDB使用的關(guān)鍵技術(shù)點。

Shared Disk架構(gòu)

分布式系統(tǒng)的精髓就在于分分合合，有時候為了并發(fā)性能進行數(shù)據(jù)切分，而有時候為了數(shù)據(jù)狀態(tài)的一致性而不得不合，或者由于分布式鎖而不得不同步等待。

PolarDB采用Shared Disk架構(gòu)，其根本原因是上述的計算與存儲分離的需要。邏輯上DB數(shù)據(jù)都放在所有DB server都能夠共享訪問的數(shù)據(jù)chunk存儲服務(wù)器上。而在存儲服務(wù)內(nèi)部，實際上數(shù)據(jù)被切塊成chunk來達到通過多個服務(wù)器并發(fā)訪問I/O的目的。

物理Replication

我們知道，MySQL Binlog記錄的是Tuple行級別的數(shù)據(jù)變更。而在InnoDB引擎層，需要支持事務(wù)ACID，也維持了一份Redo日志，存儲的是基于文件物理頁面的修改。這樣MySQL的一個事務(wù)處理默認至少需要調(diào)用兩次fsync()進行日志的持久化操作，這對事務(wù)處理的系統(tǒng)響應(yīng)時間和吞吐性能造成了直接的影響。盡管MySQL采用了Group Commit的機制來提升高并發(fā)下的吞吐量，但并不能完全消除I/O瓶頸。

此外，由于單個數(shù)據(jù)庫實例的計算和網(wǎng)絡(luò)帶寬有限，一種典型的做法是通過搭建多個只讀實例分擔(dān)讀負載來實現(xiàn)Scale out。PolarDB通過將數(shù)據(jù)庫文件以及Redolog等存放在共享存儲設(shè)備上，非常討巧的解決了只讀節(jié)點和主節(jié)點的數(shù)據(jù)Replication問題。由于數(shù)據(jù)共享，只讀節(jié)點的增加無需再進行數(shù)據(jù)的完全復(fù)制，共用一份全量數(shù)據(jù)和Redo log，只需要同步元數(shù)據(jù)信息，支持基本的MVCC，保證數(shù)據(jù)讀取的一致性即可。這使得系統(tǒng)在主節(jié)點發(fā)生故障進行Failover時候，切換到只讀節(jié)點的故障恢復(fù)時間能縮短到30秒以內(nèi)。系統(tǒng)的高可用能力進一步得到增強。而且，只讀節(jié)點和主節(jié)點之間的數(shù)據(jù)延遲也可以降低到毫秒級別。

從并發(fā)的角度來看，使用Binlog復(fù)制現(xiàn)在只能按照表級別并行復(fù)制，而物理復(fù)制只按照數(shù)據(jù)頁維度，粒度更細，并行效率更加高。

最后一點，引入Redolog來實現(xiàn)Replication的好處是，Binlog是可以關(guān)閉來減少對性能的影響，除非需要Binlog來用于邏輯上的容災(zāi)備份或者數(shù)據(jù)遷移。

總之，在I/O路徑中，通常越往底層做，越容易和上層的業(yè)務(wù)邏輯和狀態(tài)解耦而降低系統(tǒng)復(fù)雜度。而且這種WAL Redo log大文件讀寫的I/O方式也非常適用于分布式文件系統(tǒng)的并發(fā)機制，為PolarDB帶來并發(fā)讀性能的提高。

高速網(wǎng)絡(luò)下的RDMA協(xié)議

RDMA之前是在HPC領(lǐng)域被使用多年的技術(shù)手段，現(xiàn)在開始被使用到云計算領(lǐng)域，也證實我的一個判斷。云計算2.0時代，將重建人們對于云計算的認識，云端也能夠創(chuàng)造超越傳統(tǒng)IT技術(shù)的計算力，這將是一個越來越嚴謹?shù)墓I(yè)實現(xiàn)。

RDMA通常是需要有支持高速網(wǎng)絡(luò)連接的網(wǎng)絡(luò)設(shè)備（如交換機，NIC等），通過特定的編程接口，來和NIC Driver進行通訊，然后通常以Zero-Copy的技術(shù)以達到數(shù)據(jù)在NIC和遠端應(yīng)用內(nèi)存之間高效率低延遲傳遞，而不用通過中斷CPU的方式來進行數(shù)據(jù)從內(nèi)核態(tài)到應(yīng)用態(tài)的拷貝，極大的降低了性能的抖動，提高了整體系統(tǒng)的處理能力。

Snapshot物理備份

Snapshot是一種流行的基于存儲塊設(shè)備的備份方案。其本質(zhì)是采用Copy-On-Write的機制，通過記錄塊設(shè)備的元數(shù)據(jù)變化，對于發(fā)生寫操作的塊設(shè)備進行寫時復(fù)制，將寫操作內(nèi)容改動到新復(fù)制出的塊設(shè)備上，來實現(xiàn)恢復(fù)到快照時間點的數(shù)據(jù)的目的。Snapshot是一個典型的基于時間以及寫負載模型的后置處理機制。也就是說創(chuàng)建Snapshot時，并沒有備份數(shù)據(jù)，而是把備份數(shù)據(jù)的負載均分到創(chuàng)建Snapshot之后的實際數(shù)據(jù)寫發(fā)生的時間窗口，以此實現(xiàn)備份、恢復(fù)的快速響應(yīng)。PolarDB提供基于Snapshot以及Redo log的機制，在按時間點恢復(fù)用戶數(shù)據(jù)的功能上，比傳統(tǒng)的全量數(shù)據(jù)結(jié)合Binlog增量數(shù)據(jù)的恢復(fù)方式更加高效。

Parallel-Raft算法

談到分布式數(shù)據(jù)庫的事務(wù)一致性，我們很容易想到2PC（2 Phases Commit），3PC（3 Phases Commit）協(xié)議。而論數(shù)據(jù)狀態(tài)一致性，我們就不得不提到Leslie Lamport發(fā)明的Paxos協(xié)議，在Paxos為Google等互聯(lián)網(wǎng)廠商所廣泛應(yīng)用到多個分布式系統(tǒng)實現(xiàn)之后，Paxos成為了最受關(guān)注的數(shù)據(jù)狀態(tài)一致性算法之一?？墒怯捎赑axos算法論文的理論和實現(xiàn)過于復(fù)雜，導(dǎo)致難以被快速應(yīng)用到工程技術(shù)上。Paxos解決的問題之一是，在多個機器的集合中，集合中初始狀態(tài)相同的任何機器能否通過相同的命令序列到達同樣相同的狀態(tài)點，形成一個一致的收斂的狀態(tài)機。另一個問題是，作為集群中的一員，通過微觀的時間串行通訊方式，需要找到一個始終有效的協(xié)議，當(dāng)一個機器的某個數(shù)據(jù)狀態(tài)需要改變時，需要和整個集群（包括其他機器）靠通訊和協(xié)議達成相同的認知，一起認同這個機器上的某個狀態(tài)的改變。

基于這兩點，基本上就解決了分布式集群架構(gòu)中，不同角色的機器，達成一致性狀態(tài)機的問題。也就可以進一步設(shè)計出絕大多數(shù)分布式系統(tǒng)的框架。Paxos可以堪稱是P2P（Peer to Peer）的對等設(shè)計，更加抽象和通用，也更難以理解。而Raft則是選舉出Leader，再經(jīng)由Leader發(fā)起對其他角色進行狀態(tài)一致性更新的實現(xiàn)，更容易理解。而協(xié)議本身的實現(xiàn)流程和Paxos有相似之處。

Parallel-Raft是在Raft協(xié)議的基礎(chǔ)上，針對PolarDB chunk Server的I/O模型，進行改良的一致性算法。Raft協(xié)議基于Log是連續(xù)的，logn沒有提交的話，后面的Log不允許提交。而PolarDB實現(xiàn)的Parallel-Raft允許并行的提交，打破了Raft的log是連續(xù)的假設(shè)，提高并發(fā)度，通過額外的限制來確保一致性。

Docker

容器虛擬化技術(shù)最早的出現(xiàn)是Linux內(nèi)核為了解決進程在操作系統(tǒng)之間，或者在進程運行過程當(dāng)中做遷移，通過進程和操作系統(tǒng)之間的解耦，來達到進程運行時的上下文和狀態(tài)能夠保存，復(fù)制和恢復(fù)的目的?？墒荓XC的實現(xiàn)，卻促成了曾紅極一時的Docker的誕生。

從原理上講，容器虛擬化的實現(xiàn)相對于KVM等虛擬化技術(shù)而言，更加輕量級。如果用戶不需要感知整個操作系統(tǒng)的功能，那么用容器虛擬化技術(shù)理論上應(yīng)該能夠獲得更好的計算能效比。其實LXC加上Cgroup這種進程虛擬和資源隔離的方式已經(jīng)被使用很多年，在HPC領(lǐng)域就常被應(yīng)用到MPI超級任務(wù)的checkpoint和restart恢復(fù)上。PolarDB采用Docker環(huán)境來運行DB計算節(jié)點，用更輕量的虛擬化方式，解決了資源的隔離和性能的隔離，也節(jié)省了系統(tǒng)資源。

User-Space文件系統(tǒng)

談到文件系統(tǒng)，就不得不提一下IEEE發(fā)明的POSIX語義（POSIX.1已經(jīng)被ISO所接受），就像說到數(shù)據(jù)庫要談到SQL標準。通用分布式文件系統(tǒng)實現(xiàn)的最大挑戰(zhàn)就是在完全兼容POSIX標準的基礎(chǔ)上提供強勁的并發(fā)文件讀寫性能?？墒荘OSIX的兼容勢必會犧牲一部分性能來獲得對于標準的完全支持，同時系統(tǒng)實現(xiàn)的復(fù)雜度也極大的增加。說到底是通用設(shè)計和專有設(shè)計的取舍和區(qū)別，也是易用性和性能之間的平衡，這是個經(jīng)典問題。分布式文件系統(tǒng)是IT行業(yè)最經(jīng)久不衰的技術(shù)，從HPC時代，云計算時代，互聯(lián)網(wǎng)時代，大數(shù)據(jù)時代一直在推陳出新，其實更嚴格的說應(yīng)該是針對不同應(yīng)用I/O場景涌現(xiàn)出很多定制化的實現(xiàn)，再說白點，就是不去支持POSIX標準。

這一點上，只能說知難而退，不過只服務(wù)于專門的I/O場景時，不適用POSIX也不是什么問題。這一點，和從SQL到NoSQL的發(fā)展如出一轍。支持POSIX的文件系統(tǒng)，需要實現(xiàn)兼容標準的文件讀寫操作的系統(tǒng)調(diào)用接口，這樣對于用戶而言，就無需修改POSIX接口實現(xiàn)的文件操作應(yīng)用程序。這樣一來就要求通過Linux VFS層來鉚接具體的文件系統(tǒng)內(nèi)核實現(xiàn)。這也是導(dǎo)致文件系統(tǒng)工程實現(xiàn)難度加大的原因之一。

對于分布式文件系統(tǒng)而言，內(nèi)核模塊還必須和用戶態(tài)的Daemon進行數(shù)據(jù)交換，以達到數(shù)據(jù)分片以及通過Daemon進程傳送到其他機器上的目的。而User-Space文件系統(tǒng)提供用戶使用的專用API，不用完全兼容POSIX標準，也無需在操作系統(tǒng)內(nèi)核進行系統(tǒng)調(diào)用的1:1mapping對接，直接在用戶態(tài)實現(xiàn)文件系統(tǒng)的元數(shù)據(jù)管理和數(shù)據(jù)讀寫訪問支持即可，實現(xiàn)難度大大降低，并且更加有利于分布式系統(tǒng)的進程間通訊。

小結(jié)：通過以上的介紹，我們不難發(fā)現(xiàn)，PolarDB采用了從計算虛擬化，高速網(wǎng)絡(luò)互聯(lián)，存儲塊設(shè)備，分布式文件系統(tǒng)，數(shù)據(jù)庫物理Replication等全方位的技術(shù)手段，可以說是眾多熱點技術(shù)的集大成。正式這些關(guān)鍵技術(shù)的整合創(chuàng)新，才使得PolarDB的性能有了質(zhì)的飛躍。

寫在最后

阿里云PolarDB是云計算2.0時代產(chǎn)品進化的關(guān)鍵里程碑之一，也是開源數(shù)據(jù)庫生態(tài)的積極推動力。PolarDB將于2017年9月底推出的公測版本，會和MySQL完全兼容。接下來，我們也會啟動兼容PostgreSQL數(shù)據(jù)庫引擎的研發(fā)。