深度解讀 | 阿里云新一代關(guān)系型數(shù)據(jù)庫(kù) PolarDB
本文通過(guò)描述關(guān)系型數(shù)據(jù)庫(kù)發(fā)展的背景以及云計(jì)算的時(shí)代特征，分享了數(shù)據(jù)庫(kù)計(jì)算力的螺旋式上升的進(jìn)化理念，另外結(jié)合阿里云 RDS 產(chǎn)品的發(fā)展路徑，闡述了自主研發(fā)的新一代云托管關(guān)系型數(shù)據(jù)庫(kù) PolarDB 的產(chǎn)品整體設(shè)計(jì)思想，對(duì)一些關(guān)鍵技術(shù)點(diǎn)進(jìn)行了解讀。
關(guān)系型數(shù)據(jù)庫(kù)
談到關(guān)系型數(shù)據(jù)庫(kù)，在這個(gè)知識(shí)日新月異的 TMT 時(shí)代，聽(tīng)起來(lái)有些“古董”，這個(gè)起源于半個(gè)世紀(jì)以前的 IT 技術(shù)，事實(shí)上一直處于現(xiàn)代社會(huì)科技的核心，支撐著當(dāng)今世界絕大多數(shù)的商業(yè)科技文明。CPU、操作系統(tǒng)、數(shù)據(jù)庫(kù)這三大核心領(lǐng)域，基本上就是 IT 時(shí)代的縮影，同時(shí)也是一切信息化處理、計(jì)算力和智能化的基石。
從 1970 年 E.F.Codd 發(fā)表了一篇里程碑論文“A Relational Model of Data for Large Shared Data Banks”，到 80 年代初期支持 SQL 的商用關(guān)系型數(shù)據(jù)庫(kù) DB2，Oracle 的面市，以及 90 年代初 SQL-Server 的誕生，都是關(guān)系型數(shù)據(jù)庫(kù)成功的代表。
時(shí)至今日，隨著全球互聯(lián)網(wǎng)的發(fā)展，大數(shù)據(jù)技術(shù)的廣泛應(yīng)用，涌現(xiàn)出越來(lái)越多的新型數(shù)據(jù)庫(kù)，然而關(guān)系型數(shù)據(jù)庫(kù)仍然占據(jù)主導(dǎo)地位。最主要的原因之一就是關(guān)系型數(shù)據(jù)庫(kù)采用了 SQL 標(biāo)準(zhǔn)，這種高級(jí)的非過(guò)程化編程接口語(yǔ)言，將計(jì)算機(jī)科學(xué)和易于人類(lèi)理解認(rèn)知的數(shù)據(jù)管理方式完美的銜接在了一起，目前還難以超越。
SQL 語(yǔ)言
SQL(Structured Query Language) 語(yǔ)言是 1974 年由 Boyce 和 Chamberlin 提出的一種介于關(guān)系代數(shù)與關(guān)系演算之間的結(jié)構(gòu)化查詢語(yǔ)言，其本質(zhì)是用一種類(lèi)似于自然語(yǔ)言的關(guān)鍵字和語(yǔ)法來(lái)定義和操作數(shù)據(jù)，進(jìn)行可編程的數(shù)據(jù)存儲(chǔ)、查詢以及管理。
這種抽象編程接口，將具體的數(shù)據(jù)問(wèn)題與數(shù)據(jù)的存放、查詢實(shí)現(xiàn)的細(xì)節(jié)解耦開(kāi)來(lái)，使得商業(yè)業(yè)務(wù)邏輯以及信息管理的計(jì)算模式能夠被大量復(fù)制和應(yīng)用，解放了生產(chǎn)力，也極大的促進(jìn)了商業(yè)化關(guān)系型數(shù)據(jù)庫(kù)自身的發(fā)展。
從 SQL 后來(lái)不斷發(fā)展和豐富來(lái)看，SQL 已經(jīng)成為關(guān)系型數(shù)據(jù)庫(kù)語(yǔ)言的標(biāo)準(zhǔn)和王者。到今天這種編程語(yǔ)言還沒(méi)有更加完美的替代品。
OLTP
1976 年，Jim Gray 發(fā)表了名為"Granularity of Locks and Degrees of Consistency in a Shared DataBase"的論文，正式定義了數(shù)據(jù)庫(kù)事務(wù)的概念和數(shù)據(jù)一致性的機(jī)制。而 OLTP 是關(guān)系型數(shù)據(jù)庫(kù)涉及事務(wù)處理的典型應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。
事務(wù)處理需要遵循 ACID 四個(gè)要素來(lái)保證數(shù)據(jù)的正確性，包括原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。而衡量 OLTP 處理能力的性能指標(biāo)主要有響應(yīng)時(shí)間、吞吐率等。
開(kāi)源數(shù)據(jù)庫(kù)生態(tài)
在我們簡(jiǎn)要的回顧了關(guān)系型數(shù)據(jù)庫(kù)的歷史、地位和發(fā)展階段后，我們不難看到 Oracle、SQL-Server、DB2 等關(guān)系型數(shù)據(jù)庫(kù)仍然占據(jù)著全球商業(yè)數(shù)據(jù)庫(kù)的主導(dǎo)地位，雖然曾經(jīng)耳熟能詳?shù)?Informix、Sybase 已經(jīng)淡出大眾的視線。
然而，從 20 世紀(jì) 90 年代開(kāi)始，另一股推崇知識(shí)分享、自由開(kāi)放的軟件精神成為趨勢(shì)和潮流，尤其以 Linux、MySQL、PostgreSQL 等為代表的開(kāi)源軟件，開(kāi)始以強(qiáng)大的生命力不斷發(fā)展壯大，釋放出巨大的社會(huì)進(jìn)步力量，這些被自由分享的科技紅利，孕育和促進(jìn)了全球互聯(lián)網(wǎng)高科技公司的飛速發(fā)展。
這是整個(gè)人類(lèi)社會(huì)的進(jìn)步，我們要感謝那些開(kāi)源軟件的斗士們，Richard Stallman，Linus Torvalds，Michael Widenius 等。當(dāng)然，最近幾年國(guó)內(nèi)涌現(xiàn)出越來(lái)越多積極參與到開(kāi)源主流社區(qū)的中國(guó)公司，也在不斷地將技術(shù)分享回饋給開(kāi)源世界。
根據(jù) DB-engines 網(wǎng)站的最新統(tǒng)計(jì)，不難發(fā)現(xiàn)，當(dāng)把開(kāi)源數(shù)據(jù)庫(kù) MySQL 和 PostgreSQL 加在一起，開(kāi)源數(shù)據(jù)庫(kù)就已經(jīng)超越了商業(yè)數(shù)據(jù)庫(kù) Oracle，成為世界上最流行的關(guān)系型數(shù)據(jù)庫(kù)。
云計(jì)算當(dāng)前的階段
如果說(shuō)關(guān)系型數(shù)據(jù)庫(kù)是 IT 時(shí)代的產(chǎn)物。那么在互聯(lián)網(wǎng)時(shí)代的云計(jì)算，關(guān)系型數(shù)據(jù)庫(kù)目前正處于一個(gè)什么階段呢?IT 時(shí)代從某種程度上講，更多是創(chuàng)造了計(jì)算力，那么進(jìn)入互聯(lián)網(wǎng)時(shí)代的云計(jì)算，則是專(zhuān)注于用戶和計(jì)算力的連接，提供無(wú)處不在的計(jì)算力，這個(gè)其實(shí)是云計(jì)算商業(yè)模式的成功所在，可以稱之為 1.0 版本。而云計(jì)算 2.0 版本，需要在云環(huán)境下，重新進(jìn)化和升級(jí)計(jì)算力，這種進(jìn)化體現(xiàn)了社會(huì)計(jì)算力的整合以及計(jì)算資源能效的進(jìn)步。
為了順應(yīng)綠色計(jì)算以及共享經(jīng)濟(jì)的發(fā)展潮流，不僅僅需要云服務(wù)器，云數(shù)據(jù)庫(kù)，網(wǎng)絡(luò)互聯(lián)，硬件芯片等等各個(gè)軟硬件系統(tǒng)領(lǐng)域的融合以及演進(jìn)升級(jí)，還需要堅(jiān)持科技以需求為本、服務(wù)以用戶為根的科技普惠大眾的理念來(lái)進(jìn)一步促進(jìn)計(jì)算效率和計(jì)算智能的提高。
我們正處在一個(gè)蓬勃發(fā)展的云計(jì)算 2.0 階段。在這個(gè)階段，關(guān)系型數(shù)據(jù)庫(kù)在云托管環(huán)境逐漸暴露出一些問(wèn)題，作為在云計(jì)算時(shí)代的先行者，Amazon 于 2014 年 11 月 12 日 的 AWS re:Invent 2014 大會(huì)，發(fā)布 Aurora 云托管關(guān)系型數(shù)據(jù)庫(kù)就是為了解決這些問(wèn)題。這個(gè)新一代的數(shù)據(jù)庫(kù)的發(fā)布，也昭示著云計(jì)算時(shí)代，傳統(tǒng)的 IT 技術(shù)核心產(chǎn)品將揭開(kāi)自我進(jìn)化的序幕。
而 2017 年 SIGMOD 數(shù)據(jù)大會(huì)， Amazon 發(fā)布了論文”Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases”, 更加開(kāi)放的解釋了基于云環(huán)境的 Cloud-Native 設(shè)計(jì)的關(guān)系型數(shù)據(jù)庫(kù)是如何應(yīng)孕而生的。
為什么阿里云研發(fā) PolarDB ?
在我們回顧了關(guān)系型數(shù)據(jù)庫(kù)以及云計(jì)算的背景之后，我們不難發(fā)現(xiàn), 云計(jì)算 1.0 雖然解決了用戶和計(jì)算的連接的問(wèn)題，但是還需要進(jìn)一步解決在一個(gè)共享計(jì)算的環(huán)境下，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)和公有云服務(wù)環(huán)境的融合問(wèn)題。
云計(jì)算 1.0 用低廉的成本，靈活快速的部署、彈性和擴(kuò)展能力，獲得了傳統(tǒng) IT 計(jì)算上云的轉(zhuǎn)換動(dòng)力。在低成本享受普惠科技成為常態(tài)之后，隨著用戶業(yè)務(wù)的增長(zhǎng)，用戶新的痛點(diǎn)開(kāi)始出現(xiàn)，例如，如何從根本上解決用持續(xù)低的成本，享受和傳統(tǒng) IT 計(jì)算力一樣，甚至更好的云服務(wù)，成為迫切需要。
這初看起來(lái)像偽命題，仔細(xì)分析之后，卻淋漓盡致的體現(xiàn)了螺旋式上升的哲學(xué)思想。就好像在 PC 服務(wù)器涌現(xiàn)的時(shí)代，PC 服務(wù)器首先用低廉的價(jià)格提供了和小型服務(wù)器接近的計(jì)算能力，然后在保持成本和性價(jià)比優(yōu)勢(shì)的基礎(chǔ)上，實(shí)現(xiàn)了超越小型服務(wù)器的性能優(yōu)勢(shì)，直至終結(jié)了小型服務(wù)器時(shí)代，開(kāi)始了 PC 服務(wù)器時(shí)代。
所以說(shuō)云計(jì)算時(shí)代還遠(yuǎn)遠(yuǎn)沒(méi)有到達(dá)鼎盛時(shí)期，除非它通過(guò)自身進(jìn)化演變，在不斷保持性價(jià)比優(yōu)勢(shì)的同時(shí)，在具有快速靈活彈性的內(nèi)在屬性基礎(chǔ)上，擁有超過(guò)傳統(tǒng) IT 計(jì)算力的能力之后，云計(jì)算才會(huì)真正進(jìn)入它所主宰的時(shí)代，這只是個(gè)時(shí)間問(wèn)題。
也就是說(shuō)今天不只是阿里云要做這樣一款關(guān)系型數(shù)據(jù)庫(kù)，而是所有的云計(jì)算廠商都不可避免的要經(jīng)歷這樣一個(gè)階段。那就是云計(jì)算時(shí)代傳統(tǒng) IT 計(jì)算力的重建和進(jìn)化!只不過(guò) Amazon 走在了最前面，而阿里云緊跟其后，都需要經(jīng)歷這進(jìn)化到蛻變的過(guò)程。
在這個(gè)過(guò)程中，新一代關(guān)系型數(shù)據(jù)庫(kù)是關(guān)鍵的里程碑之一。同理，接下來(lái)應(yīng)該有更多更加高級(jí)的云服務(wù)，比如智能云操作系統(tǒng)出現(xiàn)，來(lái)融合為云時(shí)代設(shè)計(jì)的硬件芯片和網(wǎng)絡(luò)互聯(lián)等等。
在 IT 時(shí)代，傳統(tǒng)的計(jì)算力(例如用關(guān)系型數(shù)據(jù)庫(kù)來(lái)處理結(jié)構(gòu)化數(shù)據(jù)等)是服務(wù)于系統(tǒng)硬件隔離環(huán)境下的多用戶使用場(chǎng)景的。而云計(jì)算時(shí)代是多客戶 Self-Service 租用環(huán)境，各種計(jì)算負(fù)載場(chǎng)景更加復(fù)雜，在這種計(jì)算負(fù)載變遷的環(huán)境下，如何解決 IT 時(shí)代的技術(shù)產(chǎn)物和云計(jì)算時(shí)代應(yīng)用環(huán)境的適配矛盾，正是云計(jì)算自我進(jìn)化的內(nèi)在推動(dòng)力。
例如，在公有云環(huán)境下，隨著用戶的增多，以及用戶業(yè)務(wù)和數(shù)據(jù)的增長(zhǎng)，備份、性能、遷移、升級(jí)、只讀實(shí)例、磁盤(pán)容量、Binlog 延遲等相關(guān)問(wèn)題漸漸顯現(xiàn)出來(lái)。這背后大部分原因是由于 I/O 瓶頸(存儲(chǔ)和網(wǎng)絡(luò))導(dǎo)致，亟須通過(guò)技術(shù)革新以及新的產(chǎn)品架構(gòu)解決這個(gè)問(wèn)題。另一方面，從產(chǎn)品形態(tài)來(lái)講，阿里云 RDS 目前的產(chǎn)品形態(tài)各具優(yōu)勢(shì)，在下一節(jié)會(huì)詳細(xì)介紹。
但是從產(chǎn)品架構(gòu)的發(fā)展來(lái)看，除去數(shù)據(jù)庫(kù)存儲(chǔ)引擎的類(lèi)型之外，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，考慮到工程效率以及運(yùn)維成本，最好有一種通用的產(chǎn)品技術(shù)架構(gòu)能兼顧不同用戶場(chǎng)景的需求，而不是針對(duì)每一個(gè)場(chǎng)景都實(shí)現(xiàn)一種對(duì)應(yīng)的技術(shù)架構(gòu)。
在接下來(lái)的內(nèi)容，通過(guò)講述阿里云 RDS 的不同產(chǎn)品形態(tài)的特點(diǎn)，我們會(huì)更加清晰的了解到，PolarDB 的產(chǎn)品形態(tài)正是在吸收了之前幾種產(chǎn)品形態(tài)的優(yōu)點(diǎn)而孕育而生的。
PolarDB 的設(shè)計(jì)思想
用戶需求和公有云自身發(fā)展的選擇
作為云托管的關(guān)系型數(shù)據(jù)，除了關(guān)系型數(shù)據(jù)庫(kù)的核心特征之外。PoalrDB 更多的關(guān)注于如何提供滿足用戶業(yè)務(wù)需求的云服務(wù)，并且通過(guò)技術(shù)革新，不斷進(jìn)化，在提供更好的數(shù)據(jù)庫(kù)計(jì)算力的同時(shí)，滿足用戶以下業(yè)務(wù)需求：上云成本、OLTP 性能、業(yè)務(wù)連續(xù)性、在線業(yè)務(wù)擴(kuò)展、數(shù)據(jù)安全。
另一方面云計(jì)算除了成本優(yōu)勢(shì)之外，彈性和可擴(kuò)展性也是云計(jì)算的天然屬性。為了用戶業(yè)務(wù)的擴(kuò)展，更好的 Scale Up 以及故障恢復(fù)，計(jì)算和存儲(chǔ)分離的架構(gòu)成為云資源環(huán)境更好的選擇。這一點(diǎn)將在下一節(jié) RDS 產(chǎn)品架構(gòu)的演進(jìn)中得到進(jìn)一步的詮釋。
阿里云 RDS 產(chǎn)品架構(gòu)的演進(jìn)
如上所述，阿里云 PolarDB 和 Amazon Aurora 數(shù)據(jù)庫(kù)進(jìn)化的方向是一致的，然而進(jìn)化的路徑各有不同。本身來(lái)講，這是由于各自的數(shù)據(jù)庫(kù)云服務(wù)實(shí)現(xiàn)方式不同所決定的。阿里云 RDS MySQL 有如下幾個(gè)版本。這些產(chǎn)品形態(tài)滿足不同的用戶業(yè)務(wù)場(chǎng)景，具有不同的特點(diǎn)，可以進(jìn)行優(yōu)勢(shì)互補(bǔ)。
MySQL 基礎(chǔ)版
MySQL 基礎(chǔ)版采用數(shù)據(jù)庫(kù)計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)分離的方式，利用云盤(pán)數(shù)據(jù)本身的可靠性和多副本的特性，同時(shí)也利用了 ECS 云服務(wù)器虛擬化來(lái)提升標(biāo)準(zhǔn)化部署、版本和運(yùn)維的管理效率，能夠滿足低端用戶不太注重高可用服務(wù)的業(yè)務(wù)場(chǎng)景。
同時(shí)這種架構(gòu)對(duì)于數(shù)據(jù)庫(kù)的遷移，數(shù)據(jù)容量的擴(kuò)容，計(jì)算節(jié)點(diǎn)的 Scale Up，計(jì)算節(jié)點(diǎn)故障恢復(fù)都有天然的優(yōu)勢(shì)，根本原因就是計(jì)算和存儲(chǔ)的分離。后面也會(huì)講到，PolarDB 也采用了存儲(chǔ)和計(jì)算分離的設(shè)計(jì)理念。
MySQL 高可用版
MySQL 高可用版則是針對(duì)企業(yè)級(jí)用戶提供的高可用數(shù)據(jù)庫(kù)版本，提供 99.95% 的 SLA 保障。采用 Active-Standby 的高可用架構(gòu)，主節(jié)點(diǎn)和備節(jié)點(diǎn)之間通過(guò) MySQL Binlog 進(jìn)行數(shù)據(jù)的 Replication。當(dāng)主節(jié)點(diǎn)發(fā)生故障，備節(jié)點(diǎn)接管服務(wù)。
同時(shí)還支持多個(gè)只讀節(jié)點(diǎn)，支持負(fù)載均衡的數(shù)據(jù)讀寫(xiě)分離的訪問(wèn)方式。采用 Shared-Nothing 架構(gòu)，計(jì)算和數(shù)據(jù)位于同一個(gè)節(jié)點(diǎn)，最大程度保障性能的同時(shí)又通過(guò)數(shù)據(jù)的多副本帶來(lái)可靠性。
MySQL 金融版
MySQL 金融版可以說(shuō)是針對(duì)金融行業(yè)等高端用戶設(shè)計(jì)的高可用、高可靠云服務(wù)產(chǎn)品，采用分布式 Raft 協(xié)議來(lái)保證數(shù)據(jù)的強(qiáng)一致性，擁有更加優(yōu)異的故障恢復(fù)時(shí)間，更加滿足數(shù)據(jù)容災(zāi)備份等業(yè)務(wù)場(chǎng)景的需求。
PolarDB 的進(jìn)化
PolarDB 采用存儲(chǔ)與計(jì)算分離的技術(shù)架構(gòu)，同時(shí)可以支持更多的只讀節(jié)點(diǎn)。主節(jié)點(diǎn)和只讀節(jié)點(diǎn)之間是 Active-Active 的 Failover 方式，計(jì)算節(jié)點(diǎn)資源得到充分利用，由于使用共享存儲(chǔ)，共享同一份數(shù)據(jù)，進(jìn)一步降低了用戶的使用成本。下一節(jié)我們將進(jìn)一步從細(xì)節(jié)上描述 PolarDB 的關(guān)鍵特性。
PolarDB 的設(shè)計(jì)思想有幾個(gè)大的革新。一是通過(guò)重新設(shè)計(jì)特定的文件系統(tǒng)來(lái)存取 Redo log 這種特定的 WAL I/O 數(shù)據(jù)，二是通過(guò)高速網(wǎng)絡(luò)和高效協(xié)議將數(shù)據(jù)庫(kù)文件和 Redo log 文件放在共享存儲(chǔ)設(shè)備上，避免了多次長(zhǎng)路徑 I/O 的重復(fù)操作，相比較 Binlog 這種方式更加巧妙。
另外在 DB Server 設(shè)計(jì)上，采用 MySQL 完全兼容的思路，完全擁抱開(kāi)源生態(tài)，從 SQL 的編譯、性能優(yōu)化器和執(zhí)行計(jì)劃等等都保留了傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的特色。并且針對(duì) Redolog 的 I/O 路徑，專(zhuān)門(mén)設(shè)計(jì)了多副本共享存儲(chǔ)塊設(shè)備。
我們知道，分布式數(shù)據(jù)庫(kù)一直是數(shù)據(jù)庫(kù)領(lǐng)域的熱點(diǎn)，具有非常大的實(shí)現(xiàn)難度。不管是遵循 CAP 理論，還是 BASE 思想，通用的分布式關(guān)系型數(shù)據(jù)庫(kù)基本上很難做到技術(shù)和商用的完美平衡。與 SQL 標(biāo)準(zhǔn)以及主流數(shù)據(jù)庫(kù)兼容，OLTP ACID 事務(wù) 100% 支持，99.99% 的高可用，高性能低延遲并發(fā)處理能力，彈性 Scale Up，Scale out 可擴(kuò)展性，備份容災(zāi)和低成本遷移等等，能夠完美兼顧所有這些特點(diǎn)的商用關(guān)系型數(shù)據(jù)庫(kù)還沒(méi)有出現(xiàn)。
阿里云 PolarDB 和 Amazon Aurora 的一個(gè)共同設(shè)計(jì)哲學(xué)就是，放棄了通用分布式數(shù)據(jù)庫(kù) OLTP 多路并發(fā)寫(xiě)的支持，采用一寫(xiě)多讀的架構(gòu)設(shè)計(jì)，簡(jiǎn)化了分布式系統(tǒng)難以兼顧的理論模型，又能滿足絕大多數(shù) OLTP 的應(yīng)用場(chǎng)景和性能要求。
總之，100% MySQL 的兼容性，加上專(zhuān)用的文件系統(tǒng)和共享存儲(chǔ)塊設(shè)備設(shè)計(jì)，以及在下文中提到的多項(xiàng)高級(jí)技術(shù)的應(yīng)用，使得新一代關(guān)系型數(shù)據(jù)庫(kù) PoalrDB 在云時(shí)代必將大放異彩。
PolarDB 產(chǎn)品關(guān)鍵技術(shù)點(diǎn)剖析
在講述了阿里云 RDS 的不同產(chǎn)品形態(tài)之后，我們?cè)購(gòu)恼w上看一看 PolarDB 的產(chǎn)品架構(gòu)。下圖勾畫(huà)了 PolarDB 產(chǎn)品的主要模塊，包括數(shù)據(jù)庫(kù)服務(wù)器，文件系統(tǒng)，共享塊存儲(chǔ)等。
PoalrDB 產(chǎn)品架構(gòu)
如圖所示，PolarDB 產(chǎn)品是一個(gè)分布式集群架構(gòu)的設(shè)計(jì)。它集眾多高級(jí)的技術(shù)實(shí)現(xiàn)于一身，使得數(shù)據(jù)庫(kù) OLTP 處理性能有了質(zhì)的飛躍。PoalrDB 采用了存儲(chǔ)與計(jì)算分離的設(shè)計(jì)理念，滿足公有云計(jì)算環(huán)境下用戶業(yè)務(wù)彈性擴(kuò)展的剛性需求。數(shù)據(jù)庫(kù)計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)之間采用高速網(wǎng)絡(luò)互聯(lián)，并通過(guò) RDMA 協(xié)議進(jìn)行數(shù)據(jù)傳輸，使得 I/O 性能不在成為瓶頸。
數(shù)據(jù)庫(kù)節(jié)點(diǎn)采用和 MySQL 完全兼容的設(shè)計(jì)。主節(jié)點(diǎn)和只讀節(jié)點(diǎn)之間采用 Active-Active 的 Failover 方式，提供 DB 的高可用服務(wù)。DB 的數(shù)據(jù)文件、redolog 等通過(guò) User-Space 用戶態(tài)文件系統(tǒng)，經(jīng)過(guò)塊設(shè)備數(shù)據(jù)管理路由，依靠高速網(wǎng)絡(luò)和 RDMA 協(xié)議傳輸?shù)竭h(yuǎn)端的 Chunk Server。
同時(shí) DB Server 之間僅需同步 Redo log 相關(guān)的元數(shù)據(jù)信息。Chunk Server 的數(shù)據(jù)采用多副本確保數(shù)據(jù)的可靠性，并通過(guò) Parallel-Raft 協(xié)議保證數(shù)據(jù)的一致性。
在描述了 PolarDB 的產(chǎn)品架構(gòu)之后，我們?cè)俜謩e從分布式架構(gòu)，數(shù)據(jù)庫(kù)高可用，網(wǎng)絡(luò)協(xié)議，存儲(chǔ)塊設(shè)備，文件系統(tǒng)和虛擬化等方面逐一介紹下 PolarDB 使用的關(guān)鍵技術(shù)點(diǎn)。
Shared Disk 架構(gòu)
分布式系統(tǒng)的精髓就在于分分合合，有時(shí)候?yàn)榱瞬l(fā)性能進(jìn)行數(shù)據(jù)切分，而有時(shí)候?yàn)榱藬?shù)據(jù)狀態(tài)的一致性而不得不合，或者由于分布式鎖而不得不同步等待。
PolarDB 采用 Shared Disk 架構(gòu)，其根本原因是上述的計(jì)算與存儲(chǔ)分離的需要。邏輯上 DB 數(shù)據(jù)都放在所有 DB server 都能夠共享訪問(wèn)的數(shù)據(jù) chunk 存儲(chǔ)服務(wù)器上。而在存儲(chǔ)服務(wù)內(nèi)部，實(shí)際上數(shù)據(jù)被切塊成 chunk 來(lái)達(dá)到通過(guò)多個(gè)服務(wù)器并發(fā)訪問(wèn) I/O 的目的。
物理 Replication
我們知道，MySQL Binlog 記錄的是 Tuple 行級(jí)別的數(shù)據(jù)變更。而在 InnoDB 引擎層，需要支持事務(wù) ACID，也維持了一份 Redo 日志，存儲(chǔ)的是基于文件物理頁(yè)面的修改。
這樣 MySQL 的一個(gè)事務(wù)處理默認(rèn)至少需要調(diào)用兩次 fsync() 進(jìn)行日志的持久化操作，這對(duì)事務(wù)處理的系統(tǒng)響應(yīng)時(shí)間和吞吐性能造成了直接的影響。盡管 MySQL 采用了 Group Commit 的機(jī)制來(lái)提升高并發(fā)下的吞吐量，但并不能完全消除 I/O 瓶頸。
此外，由于單個(gè)數(shù)據(jù)庫(kù)實(shí)例的計(jì)算和網(wǎng)絡(luò)帶寬有限，一種典型的做法是通過(guò)搭建多個(gè)只讀實(shí)例分擔(dān)讀負(fù)載來(lái)實(shí)現(xiàn) Scale out。PolarDB 通過(guò)將數(shù)據(jù)庫(kù)文件以及 Redolog 等存放在共享存儲(chǔ)設(shè)備上，非常討巧的解決了只讀節(jié)點(diǎn)和主節(jié)點(diǎn)的數(shù)據(jù) Replication 問(wèn)題。
由于數(shù)據(jù)共享，只讀節(jié)點(diǎn)的增加無(wú)需再進(jìn)行數(shù)據(jù)的完全復(fù)制，共用一份全量數(shù)據(jù)和 Redo log，只需要同步元數(shù)據(jù)信息，支持基本的 MVCC，保證數(shù)據(jù)讀取的一致性即可。這使得系統(tǒng)在主節(jié)點(diǎn)發(fā)生故障進(jìn)行 Failover 時(shí)候，切換到只讀節(jié)點(diǎn)的故障恢復(fù)時(shí)間能縮短到 30 秒以內(nèi)。
系統(tǒng)的高可用能力進(jìn)一步得到增強(qiáng)。而且，只讀節(jié)點(diǎn)和主節(jié)點(diǎn)之間的數(shù)據(jù)延遲也可以降低到毫秒級(jí)別。
從并發(fā)的角度來(lái)看，使用 Binlog 復(fù)制現(xiàn)在只能按照表級(jí)別并行復(fù)制，而物理復(fù)制只按照數(shù)據(jù)頁(yè)維度，粒度更細(xì)，并行效率更加高。
最后一點(diǎn)，引入 Redolog 來(lái)實(shí)現(xiàn) Replication 的好處是，Binlog 是可以關(guān)閉來(lái)減少對(duì)性能的影響，除非需要 Binlog 來(lái)用于邏輯上的容災(zāi)備份或者數(shù)據(jù)遷移。
總之，在 I/O 路徑中，通常越往底層做，越容易和上層的業(yè)務(wù)邏輯和狀態(tài)解耦而降低系統(tǒng)復(fù)雜度。而且這種 WAL Redo log 大文件讀寫(xiě)的 I/O 方式也非常適用于分布式文件系統(tǒng)的并發(fā)機(jī)制，為 PolarDB 帶來(lái)并發(fā)讀性能的提高。
高速網(wǎng)絡(luò)下的 RDMA 協(xié)議
RDMA 之前是在 HPC 領(lǐng)域被使用多年的技術(shù)手段，現(xiàn)在開(kāi)始被使用到云計(jì)算領(lǐng)域，也證實(shí)我的一個(gè)判斷。云計(jì)算 2.0 時(shí)代，將重建人們對(duì)于云計(jì)算的認(rèn)識(shí)，云端也能夠創(chuàng)造超越傳統(tǒng) IT 技術(shù)的計(jì)算力，這將是一個(gè)越來(lái)越嚴(yán)謹(jǐn)?shù)墓I(yè)實(shí)現(xiàn)。
RDMA 通常是需要有支持高速網(wǎng)絡(luò)連接的網(wǎng)絡(luò)設(shè)備(如交換機(jī)，NIC 等)，通過(guò)特定的編程接口，來(lái)和 NIC Driver 進(jìn)行通訊，然后通常以 Zero-Copy 的技術(shù)以達(dá)到數(shù)據(jù)在 NIC 和遠(yuǎn)端應(yīng)用內(nèi)存之間高效率低延遲傳遞，而不用通過(guò)中斷 CPU 的方式來(lái)進(jìn)行數(shù)據(jù)從內(nèi)核態(tài)到應(yīng)用態(tài)的拷貝，極大的降低了性能的抖動(dòng)，提高了整體系統(tǒng)的處理能力。
Snapshot 物理備份
Snapshot 是一種流行的基于存儲(chǔ)塊設(shè)備的備份方案。其本質(zhì)是采用 Copy-On-Write 的機(jī)制，通過(guò)記錄塊設(shè)備的元數(shù)據(jù)變化，對(duì)于發(fā)生寫(xiě)操作的塊設(shè)備進(jìn)行寫(xiě)時(shí)復(fù)制，將寫(xiě)操作內(nèi)容改動(dòng)到新復(fù)制出的塊設(shè)備上，來(lái)實(shí)現(xiàn)恢復(fù)到快照時(shí)間點(diǎn)的數(shù)據(jù)的目的。
Snapshot 是一個(gè)典型的基于時(shí)間以及寫(xiě)負(fù)載模型的后置處理機(jī)制。也就是說(shuō)創(chuàng)建 Snapshot 時(shí)，并沒(méi)有備份數(shù)據(jù)，而是把備份數(shù)據(jù)的負(fù)載均分到創(chuàng)建 Snapshot 之后的實(shí)際數(shù)據(jù)寫(xiě)發(fā)生的時(shí)間窗口，以此實(shí)現(xiàn)備份、恢復(fù)的快速響應(yīng)。PolarDB 提供基于 Snapshot 以及 Redo log 的機(jī)制，在按時(shí)間點(diǎn)恢復(fù)用戶數(shù)據(jù)的功能上，比傳統(tǒng)的全量數(shù)據(jù)結(jié)合 Binlog 增量數(shù)據(jù)的恢復(fù)方式更加高效。
Parallel-Raft 算法
談到分布式數(shù)據(jù)庫(kù)的事務(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)用到多個(gè)分布式系統(tǒng)實(shí)現(xiàn)之后，Paxos 成為了最受關(guān)注的數(shù)據(jù)狀態(tài)一致性算法之一。可是由于 Paxos 算法論文的理論和實(shí)現(xiàn)過(guò)于復(fù)雜，導(dǎo)致難以被快速應(yīng)用到工程技術(shù)上。
Paxos 解決的問(wèn)題之一是，在多個(gè)機(jī)器的集合中，集合中初始狀態(tài)相同的任何機(jī)器能否通過(guò)相同的命令序列到達(dá)同樣相同的狀態(tài)點(diǎn)，形成一個(gè)一致的收斂的狀態(tài)機(jī)。另一個(gè)問(wèn)題是，作為集群中的一員，通過(guò)微觀的時(shí)間串行通訊方式，需要找到一個(gè)始終有效的協(xié)議，當(dāng)一個(gè)機(jī)器的某個(gè)數(shù)據(jù)狀態(tài)需要改變時(shí)，需要和整個(gè)集群(包括其他機(jī)器)靠通訊和協(xié)議達(dá)成相同的認(rèn)知，一起認(rèn)同這個(gè)機(jī)器上的某個(gè)狀態(tài)的改變。
基于這兩點(diǎn)，基本上就解決了分布式集群架構(gòu)中，不同角色的機(jī)器，達(dá)成一致性狀態(tài)機(jī)的問(wèn)題。也就可以進(jìn)一步設(shè)計(jì)出絕大多數(shù)分布式系統(tǒng)的框架。
Paxos 可以堪稱是 P2P(Peer to Peer)的對(duì)等設(shè)計(jì)，更加抽象和通用，也更難以理解。而 Raft 則是選舉出 Leader，再經(jīng)由 Leader 發(fā)起對(duì)其他角色進(jìn)行狀態(tài)一致性更新的實(shí)現(xiàn)，更容易理解。而協(xié)議本身的實(shí)現(xiàn)流程和 Paxos 有相似之處。
Parallel-Raft 是在 Raft 協(xié)議的基礎(chǔ)上，針對(duì) PolarDB chunk Server 的 I/O 模型，進(jìn)行改良的一致性算法。Raft 協(xié)議基于 Log 是連續(xù)的，log#n 沒(méi)有提交的話，后面的 Log 不允許提交。而 PolarDB 實(shí)現(xiàn)的 Parallel-Raft 允許并行的提交，打破了 Raft 的 log 是連續(xù)的假設(shè)，提高并發(fā)度，通過(guò)額外的限制來(lái)確保一致性。
Docker
容器虛擬化技術(shù)最早的出現(xiàn)是 Linux 內(nèi)核為了解決進(jìn)程在操作系統(tǒng)之間，或者在進(jìn)程運(yùn)行過(guò)程當(dāng)中做遷移，通過(guò)進(jìn)程和操作系統(tǒng)之間的解耦，來(lái)達(dá)到進(jìn)程運(yùn)行時(shí)的上下文和狀態(tài)能夠保存，復(fù)制和恢復(fù)的目的?？墒? LXC 的實(shí)現(xiàn)，卻促成了曾紅極一時(shí)的 Docker 的誕生。
從原理上講，容器虛擬化的實(shí)現(xiàn)相對(duì)于 KVM 等虛擬化技術(shù)而言，更加輕量級(jí)。如果用戶不需要感知整個(gè)操作系統(tǒng)的功能，那么用容器虛擬化技術(shù)理論上應(yīng)該能夠獲得更好的計(jì)算能效比。
其實(shí) LXC 加上 Cgroup 這種進(jìn)程虛擬和資源隔離的方式已經(jīng)被使用很多年，在 HPC 領(lǐng)域就常被應(yīng)用到 MPI 超級(jí)任務(wù)的 checkpoint 和 restart 恢復(fù)上。PolarDB 采用 Docker 環(huán)境來(lái)運(yùn)行 DB 計(jì)算節(jié)點(diǎn)，用更輕量的虛擬化方式，解決了資源的隔離和性能的隔離，也節(jié)省了系統(tǒng)資源。
User-Space 文件系統(tǒng)
談到文件系統(tǒng)，就不得不提一下 IEEE 發(fā)明的 POSIX 語(yǔ)義(POSIX.1 已經(jīng)被 ISO 所接受)，就像說(shuō)到數(shù)據(jù)庫(kù)要談到 SQL 標(biāo)準(zhǔn)。通用分布式文件系統(tǒng)實(shí)現(xiàn)的最大挑戰(zhàn)就是在完全兼容 POSIX 標(biāo)準(zhǔn)的基礎(chǔ)上提供強(qiáng)勁的并發(fā)文件讀寫(xiě)性能。
可是 POSIX 的兼容勢(shì)必會(huì)犧牲一部分性能來(lái)獲得對(duì)于標(biāo)準(zhǔn)的完全支持，同時(shí)系統(tǒng)實(shí)現(xiàn)的復(fù)雜度也極大的增加。說(shuō)到底是通用設(shè)計(jì)和專(zhuān)有設(shè)計(jì)的取舍和區(qū)別，也是易用性和性能之間的平衡，這是個(gè)經(jīng)典問(wèn)題。
分布式文件系統(tǒng)是 IT 行業(yè)最經(jīng)久不衰的技術(shù)，從 HPC 時(shí)代，云計(jì)算時(shí)代，互聯(lián)網(wǎng)時(shí)代，大數(shù)據(jù)時(shí)代一直在推陳出新，其實(shí)更嚴(yán)格的說(shuō)應(yīng)該是針對(duì)不同應(yīng)用 I/O 場(chǎng)景涌現(xiàn)出很多定制化的實(shí)現(xiàn)，再說(shuō)白點(diǎn)，就是不去支持 POSIX 標(biāo)準(zhǔn)。
這一點(diǎn)上，只能說(shuō)知難而退，不過(guò)只服務(wù)于專(zhuān)門(mén)的 I/O 場(chǎng)景時(shí)，不適用 POSIX 也不是什么問(wèn)題。這一點(diǎn)，和從 SQL 到 NoSQL 的發(fā)展如出一轍。支持 POSIX 的文件系統(tǒng)，需要實(shí)現(xiàn)兼容標(biāo)準(zhǔn)的文件讀寫(xiě)操作的系統(tǒng)調(diào)用接口，這樣對(duì)于用戶而言，就無(wú)需修改 POSIX 接口實(shí)現(xiàn)的文件操作應(yīng)用程序。這樣一來(lái)就要求通過(guò) Linux VFS 層來(lái)鉚接具體的文件系統(tǒng)內(nèi)核實(shí)現(xiàn)。這也是導(dǎo)致文件系統(tǒng)工程實(shí)現(xiàn)難度加大的原因之一。
對(duì)于分布式文件系統(tǒng)而言，內(nèi)核模塊還必須和用戶態(tài)的 Daemon 進(jìn)行數(shù)據(jù)交換，以達(dá)到數(shù)據(jù)分片以及通過(guò) Daemon 進(jìn)程傳送到其他機(jī)器上的目的。而 User-Space 文件系統(tǒng)提供用戶使用的專(zhuān)用 API，不用完全兼容 POSIX 標(biāo)準(zhǔn)，也無(wú)需在操作系統(tǒng)內(nèi)核進(jìn)行系統(tǒng)調(diào)用的 1:1mapping 對(duì)接，直接在用戶態(tài)實(shí)現(xiàn)文件系統(tǒng)的元數(shù)據(jù)管理和數(shù)據(jù)讀寫(xiě)訪問(wèn)支持即可，實(shí)現(xiàn)難度大大降低，并且更加有利于分布式系統(tǒng)的進(jìn)程間通訊。
小結(jié)：通過(guò)以上的介紹，我們不難發(fā)現(xiàn)，PolarDB 采用了從計(jì)算虛擬化，高速網(wǎng)絡(luò)互聯(lián)，存儲(chǔ)塊設(shè)備，分布式文件系統(tǒng)，數(shù)據(jù)庫(kù)物理 Replication 等全方位的技術(shù)手段，可以說(shuō)是眾多熱點(diǎn)技術(shù)的集大成。正式這些關(guān)鍵技術(shù)的整合創(chuàng)新，才使得 PolarDB 的性能有了質(zhì)的飛躍。
【本文為51CTO專(zhuān)欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
