作者簡介：李海翔，騰訊金融云數(shù)據(jù)庫技術(shù)專家。網(wǎng)名那海藍(lán)藍(lán)，熟悉PostgreSQL、MySQL、Informix等。數(shù)據(jù)庫內(nèi)核技術(shù)。騰訊金融云數(shù)據(jù)庫技術(shù)專家。著有《數(shù)據(jù)庫查詢優(yōu)化器的藝術(shù)》，即將出版新書《數(shù)據(jù)庫事務(wù)處理的藝術(shù)》。

導(dǎo)語：Amazon的Aurora自從問世，就備受關(guān)注，其性能和實(shí)現(xiàn)架構(gòu)是被關(guān)注的熱點(diǎn)。2017年，Amazon發(fā)表了一篇論文，披露其實(shí)現(xiàn)的一些技術(shù)細(xì)節(jié)。本文在此背景下，對Aurora系統(tǒng)的實(shí)現(xiàn)從整體架構(gòu)、存儲(chǔ)、事務(wù)處理三個(gè)方面進(jìn)行深入探討，基于其論文和相關(guān)資料討論具體實(shí)現(xiàn)細(xì)節(jié)，又跳出其外、從數(shù)據(jù)庫內(nèi)核技術(shù)實(shí)現(xiàn)的角度對Aurora做了一定的推測。接著對Aurora用技術(shù)構(gòu)建起的強(qiáng)大云數(shù)據(jù)庫服務(wù)能力進(jìn)行探索。最后總結(jié)了一些問題，以期有更多的討論和思考，一起來探索云數(shù)據(jù)庫的技術(shù)未來。

目錄

Amazon Aurora深度探索

1 Aurora的整體架構(gòu)

1.1 物理設(shè)施與架構(gòu)

1.2 核心技術(shù)與架構(gòu)

1.3 其他組件

2 Aurora的存儲(chǔ)架構(gòu)

2.1 存儲(chǔ)層的工作

2.2 儲(chǔ)存層的設(shè)計(jì)討論

2.3 Aurora設(shè)計(jì)的優(yōu)點(diǎn)

3 Aurora的事務(wù)處理

3.1 持久性

3.2 事務(wù)與數(shù)據(jù)分布

3.3 事務(wù)處理

3.4 鎖管理

4 云服務(wù)能力

4.1 強(qiáng)化的云服務(wù)能力

4.2 萬能數(shù)據(jù)庫

5 小結(jié)

附錄

?Amazon Aurora深度探索

2017年，Amazon在SIGMOD上發(fā)表了論文《Amazon Aurora: Design Considerations for High Throughput CloudNative Relational Databases》。

這篇論文，描述了Amazon的云數(shù)據(jù)庫Aurora的架構(gòu)。基于MySQL的Aurora對于單點(diǎn)寫多點(diǎn)讀的主從架構(gòu)做了進(jìn)一步的發(fā)展，使得事務(wù)和存儲(chǔ)引擎分離，為數(shù)據(jù)庫架構(gòu)的發(fā)展提供了具有實(shí)戰(zhàn)意義的已實(shí)踐用例。其主要特點(diǎn)如下：

• 實(shí)踐了“日志即數(shù)據(jù)庫”[①]的理念。

• 事務(wù)引擎和存儲(chǔ)引擎分離。

• 數(shù)據(jù)緩沖區(qū)提前預(yù)熱。

• REDO日志從事務(wù)引擎中剝離，歸并到存儲(chǔ)引擎中。

• 儲(chǔ)存層可以有6個(gè)副本，多個(gè)副本之間通過Gossip協(xié)議可以保障數(shù)據(jù)的“自愈”能力。

• 主備服務(wù)的備機(jī)可達(dá)15份，提供強(qiáng)大的讀服務(wù)能力。

• 持續(xù)可靠的云數(shù)據(jù)庫的服務(wù)能力。

• 數(shù)據(jù)存儲(chǔ)跨多個(gè)區(qū)：提供了多級別容災(zāi)能力。

• 數(shù)據(jù)容災(zāi)能力：數(shù)據(jù)冗余、備份、實(shí)時(shí)恢復(fù)等多種能力集成到云服務(wù)，提高的數(shù)據(jù)的保障能力。

萬能數(shù)據(jù)庫的概念呼之欲出。之所以有這樣的設(shè)計(jì)，是因?yàn)锳mazon認(rèn)為：網(wǎng)絡(luò)IO已經(jīng)成為數(shù)據(jù)庫最大的瓶頸[②]。

?1. Aurora的整體架構(gòu)

認(rèn)識(shí)Aurora的整體架構(gòu)，需要先理解AWS的物理設(shè)施，而論文中對Aurora基于的物理設(shè)施著墨不多，所以我們先來掌握物理設(shè)施與整體架構(gòu)的關(guān)系。

1.1 物理設(shè)施與架構(gòu)

Aurora的計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)分離，分別位于不同的VPC（Virtual Private Cloud）中。這是Aurora架構(gòu)最亮眼之處。

如圖1-1，用戶的應(yīng)用，通過Customer VPC接入，然后可以讀寫位于不同AZ(Availability Zone)的數(shù)據(jù)庫。而不同的AZ分布于全球的不同的Region中（如圖1-2[③]，截止到2017年初，AWS全球有16個(gè)區(qū)域即Region，有42個(gè)可用區(qū)即AZ，每個(gè)Region至少有2個(gè)AZ。而每個(gè)AZ由兩到多個(gè)數(shù)據(jù)中心組成，數(shù)據(jù)中心不跨AZ，每個(gè)AZ內(nèi)部的數(shù)據(jù)延遲低于0.25ms[④]。AWS文檔稱，AZ之間的延遲低于2ms通常小于1ms）。

數(shù)據(jù)庫的部署，是一主多從的集群架構(gòu)，圖1-1的Primary RW DB是寫數(shù)據(jù)的節(jié)點(diǎn)，只能有一個(gè)（這點(diǎn)說明Aurora還是傳統(tǒng)的數(shù)據(jù)庫架構(gòu)，不是真正的對等分布式架構(gòu)，這點(diǎn)也是一些批評者認(rèn)為Aurora缺乏真正創(chuàng)新之處）。而Secondary RO DB是只讀的從節(jié)點(diǎn)，由零到多個(gè)備節(jié)點(diǎn)組成，最多可以有15個(gè)。主從節(jié)點(diǎn)可以位于不同的AZ（最多位于3個(gè)VPC，需要3個(gè)AZ）但需要位于同一個(gè)Region內(nèi)，節(jié)點(diǎn)通過RDS (Relational Database Service)來交互。

RDS是由位于每個(gè)節(jié)點(diǎn)上的稱為HM(HostManager)的agent來提供主從集群的狀態(tài)監(jiān)控、以應(yīng)對主節(jié)點(diǎn)fail over的問題以便進(jìn)行HA調(diào)度、以及某個(gè)從節(jié)點(diǎn)fail over需要被替換等問題。這樣的監(jiān)控服務(wù)，稱為control plane。

圖1-1 Aurora整體架構(gòu)

圖1-2 Aurora的Region分布圖

?

數(shù)據(jù)庫的計(jì)算服務(wù)和存儲(chǔ)分離，數(shù)據(jù)緩沖區(qū)和持久化的“數(shù)據(jù)”（對于Aurora實(shí)則是日志和由日志轉(zhuǎn)化來的以page為單位的數(shù)據(jù)，而不是直接由數(shù)據(jù)緩沖區(qū)刷出的page存儲(chǔ)的數(shù)據(jù)）位于Storage VPC中，這樣和計(jì)算節(jié)點(diǎn)在物理層面隔離。一個(gè)主從實(shí)例，其物理存儲(chǔ)需要位于同一個(gè)Region中，這樣的存儲(chǔ)稱為EC2 VMs集群，其是由一個(gè)個(gè)使用了SSD的Storage Node組成。

1.2 核心技術(shù)與架構(gòu)

Aurora提倡“the log is the database”，這是其設(shè)計(jì)的核心。圍繞這個(gè)觀點(diǎn)，傳統(tǒng)數(shù)據(jù)庫的組件架構(gòu)，發(fā)生了一些變化。

對于Aurora，每一個(gè)存儲(chǔ)節(jié)點(diǎn)，如圖1-3，由兩部分構(gòu)成。

第一部分：Caching

第一部分是“Caching”，這是一個(gè)重要的關(guān)鍵點(diǎn)，可惜論文沒有描述其細(xì)節(jié)。

如同傳統(tǒng)數(shù)據(jù)庫架構(gòu)的數(shù)據(jù)緩沖區(qū)，向事務(wù)層提供數(shù)據(jù)。傳統(tǒng)數(shù)據(jù)庫架構(gòu)的數(shù)據(jù)緩沖區(qū)，向上起著消耗存儲(chǔ)IO的I加載數(shù)據(jù)到內(nèi)存供計(jì)算層讀寫數(shù)據(jù)的作用、向下起著消耗IO的O寫出臟數(shù)據(jù)到存儲(chǔ)層以實(shí)現(xiàn)數(shù)據(jù)持久存儲(chǔ)的作用。對于一個(gè)寫密集的OLTP系統(tǒng)，大量隨機(jī)寫花費(fèi)了很多時(shí)間，系統(tǒng)的性能因此經(jīng)常表現(xiàn)為存儲(chǔ)層的IO瓶頸。盡管checkpoint技術(shù)緩解了每個(gè)寫操作刷出臟數(shù)據(jù)的沖動(dòng)，盡管SSD的使用緩解了存儲(chǔ)層的瓶頸，但是，畢竟存儲(chǔ)層的I與O的時(shí)間消耗還是巨大的，尤其是對于隨機(jī)寫密集的OLTP系統(tǒng)。

Aurora的設(shè)計(jì)，消除了臟數(shù)據(jù)刷出的過程，數(shù)據(jù)緩沖區(qū)的作用，只是加載數(shù)據(jù)供上層使用，而臟數(shù)據(jù)不必從數(shù)據(jù)緩沖區(qū)刷出到物理存儲(chǔ)上，這對于隨機(jī)寫密集的OLTP系統(tǒng)而言，是一個(gè)福音，性能的瓶頸點(diǎn)被去掉了一個(gè)（如圖1-3，在“Caching”和“Logging+Storage”之間，豎線的箭頭，應(yīng)該是指向“Caching”的，以表示數(shù)據(jù)只是加載到Caching中，不存在臟數(shù)據(jù)的刷出操作）。

但是，觀察圖1-3，“Caching”是位于了存儲(chǔ)層內(nèi)還是計(jì)算層內(nèi)？論文沒有明示。

從圖1-3觀察，似乎“Caching”是存儲(chǔ)層和計(jì)算層所共用的一個(gè)組件，那么就可能存在這樣的一個(gè)兩層設(shè)計(jì)：位于存儲(chǔ)層和計(jì)算層各有一部分“Caching”，這兩部分“Caching”組合成為一個(gè)邏輯上的“Caching”，而邏輯意義上的“Caching”似乎在AWS認(rèn)為，其更像是屬于計(jì)算層的。如下文引自論文原文：

Althougheach instance still includes most of the components of a traditional kernel(query processor, transactions, locking, buffercache, access methods and undo management) several functions (redologging, durable storage, crash recovery,and backup/restore) are off-loaded tothe storage service.

位于存儲(chǔ)層內(nèi)的“Caching”，更像是一個(gè)分布式的共享文件系統(tǒng)，為了提高性能也許是一個(gè)分布式內(nèi)存型的共享文件系統(tǒng)，為主從架構(gòu)的數(shù)據(jù)庫提供高速讀服務(wù)，此點(diǎn)妙處，論文沒有點(diǎn)出，這里權(quán)做推測。存儲(chǔ)層如果能為所有的主備節(jié)點(diǎn)提供一致的緩沖數(shù)據(jù)，則有更為積極的意義，可以對比參考的如Oracle的RAC。

而位于計(jì)算層內(nèi)的“Caching”，是單個(gè)數(shù)據(jù)庫實(shí)例讀數(shù)據(jù)的場所，獨(dú)立使用。

Aurora提供了一個(gè)“自動(dòng)恢復(fù)”緩沖預(yù)熱的功能，其官方宣稱如下：

?“自動(dòng)恢復(fù)”緩存預(yù)熱

當(dāng)數(shù)據(jù)庫在關(guān)閉后啟動(dòng)或在發(fā)生故障后重啟時(shí)，Aurora 將對緩沖池緩存進(jìn)行“預(yù)熱”。即，Aurora 會(huì)用內(nèi)存頁面緩存中存儲(chǔ)的已知常用查詢頁面預(yù)加載緩沖池。這樣，緩沖池便無需從正常的數(shù)據(jù)庫使用“預(yù)熱”，從而提高性能。

Aurora 頁面緩存將通過數(shù)據(jù)庫中的單獨(dú)過程進(jìn)行管理，這將允許頁面緩存獨(dú)立于數(shù)據(jù)庫進(jìn)行“自動(dòng)恢復(fù)”。在出現(xiàn)極少發(fā)生的數(shù)據(jù)庫故障時(shí)，頁面緩存將保留在內(nèi)存中，這將確保在數(shù)據(jù)庫重新啟動(dòng)時(shí)，使用最新狀態(tài)預(yù)熱緩沖池。

源自：

http://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/Aurora.Overview.html

“在出現(xiàn)極少發(fā)生的數(shù)據(jù)庫故障時(shí)，頁面緩存將保留在內(nèi)存中”，這句話很重要，一是其表明數(shù)據(jù)不用很耗時(shí)地重新加載了，二是數(shù)據(jù)庫實(shí)例崩潰前的數(shù)據(jù)內(nèi)存狀態(tài)被保留著，三是數(shù)據(jù)庫崩潰重啟不必再執(zhí)行“故障恢復(fù)”的過程即使用REDO日志重新回放以保障數(shù)據(jù)的一致性了（事務(wù)的ACID中的C特性）。

那么，頁面緩沖是一直保留在哪個(gè)節(jié)點(diǎn)的內(nèi)存中？是存儲(chǔ)節(jié)點(diǎn)還是計(jì)算節(jié)點(diǎn)？如果是位于計(jì)算節(jié)點(diǎn)，那么備機(jī)節(jié)點(diǎn)發(fā)生數(shù)據(jù)庫故障時(shí)，這樣的機(jī)制不會(huì)對備機(jī)節(jié)點(diǎn)起到保護(hù)作用。如果是位于存儲(chǔ)節(jié)點(diǎn)，則存儲(chǔ)作為一個(gè)服務(wù)，服務(wù)了一主多備的多個(gè)節(jié)點(diǎn)，則能更好的發(fā)揮“自動(dòng)恢復(fù)”緩沖預(yù)熱的功效（存儲(chǔ)節(jié)點(diǎn)的caching一直存在，向上層計(jì)算節(jié)點(diǎn)的caching提供數(shù)據(jù)批量加載服務(wù)，但也許不是這樣，而是提供一個(gè)接口，能夠向計(jì)算層的caching提供高速讀數(shù)據(jù)的服務(wù)，論文沒有更多的重要細(xì)節(jié)披露，權(quán)做推測）。由此看來，“Caching”層的兩層設(shè)計(jì)，當(dāng)是有價(jià)值的（價(jià)值點(diǎn)是“自動(dòng)恢復(fù)”緩沖預(yù)熱，由存儲(chǔ)層提供此項(xiàng)服務(wù)），與預(yù)寫日志功能從事務(wù)層剝離是關(guān)聯(lián)的設(shè)計(jì)。

這就又回到前面引用的論文中的那段英文，其表明：Aurora的設(shè)計(jì)，把REDO日志、持久化存儲(chǔ)、系統(tǒng)故障恢復(fù)、物理備份與物理恢復(fù)這些功能模塊，歸屬到了存儲(chǔ)層。由此就引出了Aurora的另外一個(gè)重要話題---存儲(chǔ)層的設(shè)計(jì)（如下的第二部分和下一節(jié)內(nèi)容）。

對于計(jì)算層的“Caching”，其實(shí)現(xiàn)將被大為簡化。臟數(shù)據(jù)不再被寫出，臟頁面不再需要復(fù)雜的淘汰策略進(jìn)行管理，消除了后臺(tái)的寫任務(wù)線程，同時(shí)也消除了checkpoint線程的工作，數(shù)據(jù)緩沖區(qū)的管理大為簡化，即降低了系統(tǒng)的復(fù)雜度又減少了時(shí)間的消耗、還避免了因執(zhí)行后臺(tái)寫等任務(wù)帶來的性能抖動(dòng)，解耦帶來的功效確實(shí)宜人。Aurora額外需要做的一項(xiàng)新工作是：only pages with a long chain of modifications need to berematerialized。而計(jì)算層的“Caching”變成單向的讀入，此時(shí)需要解決的，僅僅是什么樣的數(shù)據(jù)可以（從存儲(chǔ)層的Caching）被讀入的問題，而論文原文描述：

Theguarantee is implemented by evicting a page from the cache only if its “pageLSN” (identifying the log record associated with the latest change to the page)is greater than or equal tothe VDL. ?

VDL是存儲(chǔ)層的最小一致點(diǎn)（參見3.1節(jié)），標(biāo)識(shí)了可用日志的最低范圍，比VDL還老的數(shù)據(jù)頁不再可用，所以顯然如上的論文原文是錯(cuò)誤的。如果有比當(dāng)前數(shù)據(jù)頁還新的數(shù)據(jù)頁被從日志中恢復(fù)，則其LSN一定更大，所以頁面換入的條件是：存儲(chǔ)層Caching中存在頁面的LSN值更大的；頁面被換出的條件是：Caching中的頁面的LSN小于等于VDL。而且，這一定是發(fā)生在備機(jī)需要更新其計(jì)算層的Caching時(shí)刻，而不是主機(jī)需要更新其計(jì)算層的Caching時(shí)刻。存在此種情況，其原因已經(jīng)很明顯，主機(jī)修改數(shù)據(jù)，形成臟頁，這樣的臟頁（數(shù)據(jù)的后像）才能作為REDO日志的一部分被主機(jī)刷出；而主機(jī)不會(huì)刷出臟頁，所以被修改后的數(shù)據(jù)頁應(yīng)該一直在內(nèi)存中，而被修改過的數(shù)據(jù)頁如果反復(fù)被修改，則意味著主機(jī)Caching中的相應(yīng)臟頁數(shù)據(jù)一定是最新的，沒有必要從存儲(chǔ)層的Caching中讀入“繞道恢復(fù)后的數(shù)據(jù)頁”。如果以上猜想不成立，除非Aurora生成REDO日志時(shí)，存于REDO日志中的數(shù)據(jù)頁部分采取先復(fù)制然后其上的數(shù)據(jù)項(xiàng)被修改這樣的方式。可是多做一次復(fù)制，又有何必要呢？

?

圖1-3 存儲(chǔ)結(jié)構(gòu)圖

?

另外，如果“Caching”確實(shí)存在兩層（另外一個(gè)證據(jù)，參加圖1-4[⑤]），而如2.1節(jié)所述，存儲(chǔ)層也在處理日志、并依據(jù)日志生成頁數(shù)據(jù)，則存儲(chǔ)節(jié)點(diǎn)也存在處理數(shù)據(jù)的能力，就類似于Oracle的ExaData。這樣導(dǎo)致的一個(gè)可能是，兩層的“Caching”還是可能存在差別的。存儲(chǔ)層的“Caching”能夠幫助做謂詞下推的工作，然后把較少的數(shù)據(jù)傳回計(jì)算層的“Caching”，由此實(shí)現(xiàn)類似Oracle的ExaData的智能掃描（Smart Scan）的功能。是否如此，或者Aorora的體系結(jié)構(gòu)和功能模塊在未來繼續(xù)演變的時(shí)候，是否會(huì)在存儲(chǔ)層內(nèi)的“Caching”做足文章，可以拭目以待。不過，目前制約存儲(chǔ)層內(nèi)的“Caching”起更大作用的因素，主要在于分布式事務(wù)的機(jī)制的選取和InnoDB自身的事務(wù)實(shí)現(xiàn)機(jī)制。詳細(xì)討論參見3.2節(jié)。

圖1-4 存儲(chǔ)層的“Shared storage column”與計(jì)算層的“Caching”構(gòu)成的兩層數(shù)據(jù)緩沖結(jié)構(gòu)

第二部分：Logging+Storage

第二部分是“Logging+Storage”，日志和持久化存儲(chǔ)。日志與傳統(tǒng)數(shù)據(jù)庫對于預(yù)寫日志（WAL）的利用方式與MySQL不同，這點(diǎn)是Aurora實(shí)現(xiàn)計(jì)算與存儲(chǔ)分離的核心（下一節(jié)詳述存儲(chǔ)層實(shí)現(xiàn)細(xì)節(jié)）。

如圖1-5所示，對于日志數(shù)據(jù)，從Primary RW DB寫出到一個(gè)存儲(chǔ)節(jié)點(diǎn)，每個(gè)AZ至少有2份數(shù)據(jù)，寫出的日志數(shù)據(jù)會(huì)自動(dòng)復(fù)制到3個(gè)AZ中的6個(gè)存儲(chǔ)節(jié)點(diǎn)，當(dāng)其中的多數(shù)節(jié)點(diǎn)回應(yīng)寫日志成功，則向上層返回寫成功的ACK。這表明寫日志信息采用了多數(shù)派協(xié)議（quorum）。

MySQL的事務(wù)模型符合SS2PL協(xié)議[⑥]，當(dāng)日志成功寫出，就可以在內(nèi)存中標(biāo)識(shí)事務(wù)提交成功[⑦]，而寫日志信息是一個(gè)批量的、有序的IO操作，再加上Aurora去除了大量的緩沖區(qū)臟數(shù)據(jù)的隨機(jī)寫操作，因此Aurora的整體性能得到大幅提升。

借用官方論文的一組對比數(shù)據(jù)，可以感性認(rèn)識(shí)存儲(chǔ)和計(jì)算分離的所帶來的巨大好處，如圖1-6所示，MySQL的每個(gè)事務(wù)的IO花費(fèi)是Aurora的7.79倍，而事務(wù)處理量Aurora是MySQL的35倍，相差明顯。

圖1-5 主從復(fù)制日志存儲(chǔ)圖?

圖1-6 Aurora與MySQL主從復(fù)制架構(gòu)性能數(shù)據(jù)對比圖

?

對于主備系統(tǒng)之間，如圖1-5所示，主備之間有事務(wù)日志（LOG）和元數(shù)據(jù)（FRM FILES）的傳遞。也就是說備機(jī)的數(shù)據(jù)是源自主機(jī)的。如圖1-5所示的主備之間的紫色箭頭，表示主機(jī)向備機(jī)傳輸?shù)氖歉铝说脑獢?shù)據(jù)，綠色箭頭表示日志作為數(shù)據(jù)流被發(fā)送給了備機(jī)（這個(gè)復(fù)制，應(yīng)該是異步的，相關(guān)內(nèi)容請參考2.1節(jié)）。所以備機(jī)的數(shù)據(jù)更新，應(yīng)該是應(yīng)用了主機(jī)傳輸來的事務(wù)日志所致。這是論文中表述的內(nèi)容，原文如下：

In this model,the primary only writes log records to the storage service and streams those logrecords as well as metadata updates to the replica instances.

但是，日志的應(yīng)用功能是被放到了存儲(chǔ)層實(shí)現(xiàn)的，如原文描述：

Instead,the log applicator is pushed to thestorage tier where it can be used to generate database pages inbackground or on demand.

而官方的網(wǎng)站[⑧]用圖1-7描述了備機(jī)的數(shù)據(jù)，是從存儲(chǔ)節(jié)點(diǎn)讀入的。

鑒于以上幾點(diǎn)，備機(jī)數(shù)據(jù)獲取和更新的這個(gè)細(xì)節(jié)，算是個(gè)謎。

“Caching”如果確實(shí)分為兩層，在存儲(chǔ)層提供從日志中恢復(fù)成為數(shù)據(jù)頁的形式而被緩沖，則主備系統(tǒng)之間應(yīng)該沒有必要再傳輸日志數(shù)據(jù)，對于備機(jī)而言，直接從統(tǒng)一的存儲(chǔ)層的“Caching”中獲取數(shù)據(jù)即可。

與此相關(guān)的一個(gè)問題是：為什么備機(jī)節(jié)點(diǎn)，可以多達(dá)15個(gè)呢？難道僅僅是應(yīng)對讀負(fù)載嗎？或者，作為故障轉(zhuǎn)移的目標(biāo)，需要這么多備機(jī)做備選嗎？這又是一個(gè)謎。

圖1-7 Aurora主備機(jī)數(shù)據(jù)流圖

1.3 其他組件

從圖1-1中可以看到，物理備份和恢復(fù)的數(shù)據(jù)，是直接存儲(chǔ)在Amazon S3，即Simple Storage Service上。物理備份和恢復(fù)的模塊功能被從事務(wù)引擎中剝離到了存儲(chǔ)層。

從圖1-3和1-4中可以看到，日志信息的持久化存儲(chǔ)，也是落在了S3上。

S3是AWS提供的對象存儲(chǔ)服務(wù)。S3提供了高耐久性、高可擴(kuò)展性以及安全的解決方案來備份和歸檔用戶的關(guān)鍵數(shù)據(jù)。在云服務(wù)中，數(shù)據(jù)庫提供商業(yè)邏輯的支撐，S3提供了數(shù)據(jù)的持久存儲(chǔ)支撐。其作用不可小視。

另外，論文提及了heat management、OS and security patching 、software upgrades等特性，對于創(chuàng)造極高的云數(shù)據(jù)庫服務(wù)能力很有幫助，本文不再展開討論，請參閱論文和相關(guān)資料。

2 .Aurora的存儲(chǔ)架構(gòu)

存儲(chǔ)層的設(shè)計(jì)和實(shí)現(xiàn)，體現(xiàn)了“the log is the database”，其含義是日志中包含了數(shù)據(jù)的信息，可以從日志中恢復(fù)出用戶的數(shù)據(jù)，所以數(shù)據(jù)不一定必須再獨(dú)立存儲(chǔ)一份。而數(shù)據(jù)庫的核心不僅是數(shù)據(jù)，保障數(shù)據(jù)的擁有ACID特性的事務(wù)和提供便捷查詢的SQL語句、對以數(shù)據(jù)為基礎(chǔ)提供商業(yè)的交易服務(wù)更是必不可缺失，所以更精確的說，“the log is the data”，日志就是數(shù)據(jù)也許更為合適。在筆者看來，數(shù)據(jù)庫的價(jià)值不僅在數(shù)據(jù)，還在數(shù)據(jù)庫的相關(guān)技術(shù)，尤其在現(xiàn)代巨量數(shù)據(jù)下、完備的數(shù)據(jù)庫理論下，對以分布為要求的數(shù)據(jù)庫架構(gòu)提出新的工程實(shí)踐挑戰(zhàn)。Aurora就是走在這樣的實(shí)踐道路上的楷模。

2.1 存儲(chǔ)層的工作

如圖1-8所示，主機(jī)Primary RW DB寫出的REDO日志（MySQL生成的日志帶有LSN，Log Sequence Number，單調(diào)遞增的日志順序號）信息發(fā)送到六個(gè)Sotrage Node中的每一個(gè)Sotrage Node上的時(shí)候，只存在一個(gè)同步瓶頸點(diǎn)，就是圖中標(biāo)識(shí)為?之處，這是Aurora的一個(gè)核心設(shè)計(jì)點(diǎn)，盡量最小化主節(jié)點(diǎn)寫請求的延時(shí)。在存儲(chǔ)節(jié)點(diǎn)，傳輸來的日志進(jìn)入一個(gè)隊(duì)列等待被處理。

之后日志被快速持久化到物理存儲(chǔ)設(shè)備，并立刻給主機(jī)一個(gè)回應(yīng)。這是標(biāo)識(shí)為?的處理過程，這個(gè)過程極其簡單，沒有額外的操作，因而速度會(huì)很快，這樣能夠滿足如上所說的“盡量最小化主節(jié)點(diǎn)寫請求的延時(shí)”的設(shè)計(jì)理念。?和?之后的其他操作，都是異步操作，不影響系統(tǒng)的整體性能。這樣當(dāng)主機(jī)Primary RW DB收到六個(gè)Sotrage Node中的四個(gè)節(jié)點(diǎn)的ACK后，就認(rèn)為日志成功寫出，可以繼續(xù)其他工作了

?所做的工作，是對持久化了日志做處理，如排序/分組等操作作用在日志上，以便找出日志數(shù)據(jù)中的間隙，存在間隙的原因是多數(shù)派寫日志的機(jī)制下，少數(shù)派可能丟失日志從而導(dǎo)致日志不連貫。

?所做的工作，就是從其他存儲(chǔ)節(jié)點(diǎn)（6個(gè)存儲(chǔ)節(jié)點(diǎn)構(gòu)成一個(gè)PG ，即Protection Group，每個(gè)節(jié)點(diǎn)是一個(gè)segment，存儲(chǔ)單位是10G，位于一個(gè)數(shù)據(jù)中心中。6個(gè)存儲(chǔ)節(jié)點(diǎn)每2個(gè)位于一個(gè)AZ，共分布于3個(gè)AZ）中，通過Gossip協(xié)議，來拉取本節(jié)點(diǎn)丟失的日志數(shù)據(jù)，以填充滿所?發(fā)現(xiàn)的日志間隙。在?和?的過程中，能發(fā)現(xiàn)所有的副本中：相同的、連續(xù)的日志段是哪一部分，其中最大的LSN被稱為VCL（Volume Complete LSN）。

?所做的工作，就是從持久化的日志數(shù)據(jù)中，產(chǎn)生數(shù)據(jù)，就如同系統(tǒng)故障時(shí)使用REDO日志做恢復(fù)的過程：解析REDO日志，獲取其中保存的數(shù)據(jù)頁的修改后像，恢復(fù)到類似于傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)緩沖區(qū)中（這也是存儲(chǔ)層需要存在“Caching”的一個(gè)明證）。

之后，第六步，周期性地把修復(fù)后的日志數(shù)據(jù)和由日志生成的以頁為單位的數(shù)據(jù)刷出到S3做為備份。第七步，周期性地收集垃圾版本（PGMRPL，即Protection Group Min Read Point LSN），參考表1-2[⑨]，可以看到，垃圾收集，是以VDL為判斷依據(jù)的，當(dāng)日志的LSN小于VDL，則可以被作為垃圾回收；第八步，周期性地用CRC做數(shù)據(jù)校驗(yàn)。

圖1-8 日志數(shù)據(jù)在存儲(chǔ)節(jié)點(diǎn)的處理過程圖

2.2 儲(chǔ)存層的設(shè)計(jì)討論

現(xiàn)在再來反觀Aurora的整體設(shè)計(jì)：

數(shù)據(jù)不再從數(shù)據(jù)緩沖區(qū)刷出，消除了隨機(jī)寫操作，減少了IO。

計(jì)算和存儲(chǔ)分離，日志跨AZ寫到多份存儲(chǔ)節(jié)點(diǎn)，存在網(wǎng)絡(luò)IO。

主備節(jié)點(diǎn)間傳輸日志和元數(shù)據(jù)，存在網(wǎng)絡(luò)IO。

如上是三條核心點(diǎn)，似乎網(wǎng)絡(luò)IO占了三分之二條，屬于多數(shù)。但是網(wǎng)絡(luò)IO都是批量數(shù)據(jù)順序?qū)?#xff0c;可極大地抵消很多次的隨機(jī)寫的網(wǎng)絡(luò)IO消耗，而且通過數(shù)據(jù)冗余，極大地保障了可用性和云數(shù)據(jù)的彈性，從測試數(shù)據(jù)看，整體性能得到了可觀的提升。因此這樣的設(shè)計(jì)是一個(gè)優(yōu)秀的架構(gòu)設(shè)計(jì)。

數(shù)據(jù)冗余且有效，是使用數(shù)據(jù)庫系統(tǒng)的基本要求。邏輯備份與還原、物理備份與恢復(fù)、主從復(fù)制、兩地三中心等災(zāi)備技術(shù)方案等都是數(shù)據(jù)冗余的相關(guān)技術(shù)。數(shù)據(jù)庫走向?qū)Φ确植际郊軜?gòu)，除了應(yīng)對巨量數(shù)據(jù)的存儲(chǔ)和計(jì)算的需要，也要靠數(shù)據(jù)冗余來保證數(shù)據(jù)的可用性。所以數(shù)據(jù)冗余是數(shù)據(jù)系統(tǒng)架構(gòu)設(shè)計(jì)的一個(gè)必須考慮點(diǎn)。

Aurora自然也要實(shí)現(xiàn)數(shù)據(jù)冗余。如圖1-5所示，數(shù)據(jù)至少在3個(gè)AZ中存6份。如果不采用“the log is the database”的理念，而使用傳統(tǒng)數(shù)據(jù)庫的技術(shù)，在跨節(jié)點(diǎn)寫出多份數(shù)據(jù)時(shí)，勢必需要采用2PC/3PC等多階段的方式來保證提交數(shù)據(jù)的正確性，這樣網(wǎng)絡(luò)交互的次數(shù)就會(huì)很多，而且大量的隨機(jī)寫操作會(huì)在網(wǎng)絡(luò)蔓延。所以“the log is the database”的理念客觀上避免了傳統(tǒng)的、耗時(shí)昂貴的分布式事務(wù)的處理機(jī)制，而又達(dá)到了數(shù)據(jù)分布的目的，這又是一個(gè)亮點(diǎn)。

數(shù)據(jù)至少在3個(gè)AZ中存6份，其目的是要保證數(shù)據(jù)庫服務(wù)的持續(xù)可用。那么，什么算是可用呢？無論是數(shù)據(jù)中心內(nèi)部的局部故障還是跨數(shù)據(jù)中心甚至跨AZ出現(xiàn)故障，AWS也要在某些情況下提供數(shù)據(jù)服務(wù)的可用。這就要分兩種情況確定，這兩種情況基于6個(gè)副本的前提[⑩]（3個(gè)副本能滿足多數(shù)派的讀寫規(guī)則，但是一旦其中一個(gè)副本不可用，則其余2個(gè)就不能保證讀寫一致，基于3個(gè)副本的分布式設(shè)計(jì)是脆弱的，不能切實(shí)可用地起到依靠數(shù)據(jù)冗余來換取數(shù)據(jù)可用的保障）：

第1種： 讀寫均可用。

如圖1-9，當(dāng)一個(gè)AZ出現(xiàn)問題，即2個(gè)副本不可用，Aurora仍然能夠保證讀寫可用，保障數(shù)據(jù)一致。設(shè)置V=6，讀多數(shù)派為Vr = 3，寫多數(shù)派為Vw = 4，所以一個(gè)AZ出現(xiàn)故障，或者3個(gè)AZ中的兩個(gè)數(shù)據(jù)中心出現(xiàn)故障，Aurora依然能夠向外提供服務(wù)。

圖1-9 Aurora保障讀寫可用圖

?

第2種： 至少讀可用。

當(dāng)寫服務(wù)不可用，至少還可以提供讀服務(wù)。設(shè)置V=6，讀多數(shù)派為Vr = 3，寫多數(shù)派為Vw = 4時(shí)，一個(gè)AZ出現(xiàn)故障依舊能夠提供讀服務(wù)，如圖1-10甚至跨不同AZ的3個(gè)數(shù)據(jù)中心出現(xiàn)故障（概率非常小），讀服務(wù)依舊能夠提供。

圖1-10 Aurora保障讀可用圖

?

在1.1節(jié)，曾經(jīng)說過“主從節(jié)點(diǎn)可以位于不同的AZ（最多位于3個(gè)VPC，需要3個(gè)AZ）但需要位于同一個(gè)Region內(nèi)”。如表1-1所示，AWS在全球提供的AZ個(gè)數(shù)尚有限，按其自身的說法部署一個(gè)Aurora需要三個(gè)AZ，那么諸如只有2個(gè)AZ的Region如北京，尚不能得到較可靠的數(shù)據(jù)可用保障。

表1-1 至2017年6月AWS的Region和AZ部署表

2.3 Aurora設(shè)計(jì)的優(yōu)點(diǎn)

首先，存儲(chǔ)層與事務(wù)管理分離，即ACID的D特性獨(dú)立，使得存儲(chǔ)有機(jī)會(huì)成為獨(dú)立的服務(wù)而存在，便于跨數(shù)據(jù)中心時(shí)實(shí)現(xiàn)數(shù)據(jù)的容錯(cuò)（fault-tolerant）、自愈（self-healing service）[11]和快速遷移。一旦存儲(chǔ)層具備了容錯(cuò)、自愈和可快速遷移特性，則對外提供服務(wù)就不用再擔(dān)心數(shù)據(jù)的短暫或長久的不可用性。在數(shù)據(jù)為王的時(shí)代，此舉能保護(hù)好最核心的財(cái)產(chǎn)，確保云數(shù)據(jù)庫服務(wù)能持續(xù)不斷地對外提供服務(wù)，這使得Aurora具備了云服務(wù)的彈性。此點(diǎn)在AWS看來，十分重要。有了這種需求，推動(dòng)技術(shù)架構(gòu)發(fā)生變化便水到渠成。

服務(wù)的過程中，局部數(shù)據(jù)修復(fù)的能力，速度很快。數(shù)據(jù)庫宕機(jī)后的恢復(fù)，速度也很快。

Once thedatabase starts up it performs volume recovery in collaboration with thestorage service and as a result, an Aurora database can recover very quickly (generally under 10 seconds) even ifit crashed while processing over 100,000write statements per second.

服務(wù)中斷后，最后的招數(shù)就是數(shù)據(jù)遷移加數(shù)據(jù)庫引擎重新部署，而AWS的整個(gè)云系統(tǒng)具備了快速遷移數(shù)據(jù)的能力，這使得以存儲(chǔ)為核心的云數(shù)據(jù)庫有了超強(qiáng)的持久服務(wù)能力。 ??

Wemonitor and automatically repair faults as part of our service. A 10GB segment can be repaired in 10 seconds on a10Gbps network link. We would need to see two such failures in thesame 10 second window plus a failure of an AZ not containing either of thesetwo independent failures to lose quorum. At our observed failure rates, that’ssufficiently unlikely, even for the number of databases we manage for ourcustomers.

其次，存儲(chǔ)層從高度耦合的數(shù)據(jù)庫引擎中分離，降低了數(shù)據(jù)庫引擎的復(fù)雜度，數(shù)據(jù)庫組件的分離使得數(shù)據(jù)庫部署適應(yīng)巨量數(shù)據(jù)的分布式處理需求。這將進(jìn)一步帶動(dòng)數(shù)據(jù)庫引擎上層的語法分析、查詢優(yōu)化、SQL執(zhí)行、事務(wù)處理等組件進(jìn)一步的解耦。

筆者認(rèn)為，這是Aurora用實(shí)踐為數(shù)據(jù)庫架構(gòu)技術(shù)的發(fā)展指出的可行方向。一個(gè)具有實(shí)踐意義的分布式發(fā)展架構(gòu)，總是最亮眼的，也總是具有指導(dǎo)意義的。存儲(chǔ)與計(jì)算解耦，各種組件互相解耦，不斷解耦...在此種思路下，AWS已經(jīng)走在發(fā)展萬能數(shù)據(jù)庫引擎的道路上（參見4.2節(jié)）。

?

3.Aurora的事務(wù)處理

Aurora基于MySQL和InnoDB，實(shí)現(xiàn)的是單點(diǎn)寫的一主多從架構(gòu)，所以在事務(wù)處理方面，沒有大的變動(dòng)，事務(wù)處理技術(shù)得到繼承。整體上是依據(jù)SS2PL和MVCC技術(shù)實(shí)現(xiàn)了事務(wù)模型（參見《數(shù)據(jù)庫事務(wù)處理的藝術(shù) 事務(wù)管理與并發(fā)控制》一書的10.3.3、10.3.4節(jié)）和并發(fā)控制（參見《數(shù)據(jù)庫事務(wù)處理的藝術(shù)事務(wù)管理與并發(fā)控制》一書的第11、12章）。

3.1 持久性

對于Aurora，事務(wù)的ACID特性，只有D特性與MySQL和InnoDB有很大的不同。Aurora利用MySQL的Mini-transaction和LSN在存儲(chǔ)節(jié)點(diǎn)構(gòu)造數(shù)據(jù)頁（基本過程參見2.1節(jié)）。

如前所述，Aurora的存儲(chǔ)層與計(jì)算層分離。存儲(chǔ)層其功能在2.1節(jié)討論，其設(shè)計(jì)思想在2.2節(jié)討論。本節(jié)從事務(wù)的角度來討論與存儲(chǔ)層緊密相關(guān)的持久性，如表1-2所示存儲(chǔ)層是表中的“存儲(chǔ)節(jié)點(diǎn)S1、S2、S3、S4、S5、S6”。

在存儲(chǔ)層，日志被寫到持久化的存儲(chǔ)設(shè)備后，主節(jié)點(diǎn)收到應(yīng)答則不被阻塞，上層工作能夠繼續(xù)進(jìn)行，且存儲(chǔ)層的日志落盤操作保證了整個(gè)Aorora的日志持久化。然后存儲(chǔ)層的利用日志做實(shí)時(shí)恢復(fù)，這樣使得日志數(shù)據(jù)轉(zhuǎn)變?yōu)榱恕癈aching”中存儲(chǔ)的頁面格式的數(shù)據(jù)。這些工作完成，才相當(dāng)于傳統(tǒng)架構(gòu)的數(shù)據(jù)庫持久化完成。

但是，因?yàn)榇鎯?chǔ)層不再是單點(diǎn)而是分布式結(jié)構(gòu)，故存在故障的種類變多，如多節(jié)點(diǎn)的數(shù)據(jù)在實(shí)時(shí)運(yùn)行過程中的一致性問題、在系統(tǒng)故障后的數(shù)據(jù)恢復(fù)時(shí)多節(jié)點(diǎn)的數(shù)據(jù)一致性問題。Aurora使用如表1-2的幾個(gè)概念來表示關(guān)鍵的一些日志點(diǎn)信息，然后憑借這些點(diǎn)來解決“日志數(shù)據(jù)的不一致”問題，這幾個(gè)概念，分別是：

LSN, Log Sequence Number，日志序列號：單調(diào)遞增，唯一標(biāo)識(shí)每一條日志記錄。如表1-2所示，LSN1到LSN9表示共有9條日志記錄，每條有獨(dú)立的LSN值。

CPL, Consistency Point LSN，一致性點(diǎn)：MySQL的每個(gè)Mini事務(wù)產(chǎn)生的最后一個(gè)LSN為一個(gè)CPL即一致性點(diǎn)（一個(gè)事務(wù)包括多個(gè)Mini事務(wù)，一個(gè)Mini事務(wù)包括一到多個(gè)日志記錄。這是在描述以Mini事務(wù)為基本單位的一個(gè)局部一致，尚不能達(dá)到事務(wù)一致）。如表1-2所示，“T1-Mini-t1”T1事務(wù)的第一個(gè)Mini事務(wù)的一致性點(diǎn)，是LSN3，如果此時(shí)系統(tǒng)故障，之后做恢復(fù)，事務(wù)T1不會(huì)被恢復(fù)成功；如果事務(wù)T1在主節(jié)點(diǎn)被標(biāo)識(shí)為了提交（InnoDB的事務(wù)提交標(biāo)志，是在內(nèi)存標(biāo)識(shí)為事務(wù)已經(jīng)提交，然后才刷出日志，這點(diǎn)不符合預(yù)寫日志的要求），事務(wù)日志尚沒有持久化到存儲(chǔ)層，這意味著數(shù)據(jù)可能會(huì)丟失。但是，InnoDB對這種先標(biāo)識(shí)事務(wù)提交后刷日志的方式給出了不丟失數(shù)據(jù)的解決方式，而Aurora改變了日志的刷出機(jī)制，可能會(huì)改變或不改變InnoDB原有的數(shù)據(jù)一致性保障機(jī)制[12]，如果改變了原有機(jī)制，論文對這一個(gè)重要點(diǎn)沒有加以描述，只能存疑待問。

SCL，Segment CompleteLSN，段完整LSN：每一個(gè)存儲(chǔ)節(jié)點(diǎn)對應(yīng)的最大連續(xù)LSN，在系統(tǒng)存活期間，可以利用SCN與其它節(jié)點(diǎn)交互，采用Gossip協(xié)議，填補(bǔ)丟失的日志記錄。如表1-2所示，只標(biāo)識(shí)出了S1節(jié)點(diǎn)的SCL是LSN9，而對于S5節(jié)點(diǎn)，其SCL是LSN7。

VCL，Volume Complete LSN，卷完整LSN：每個(gè)存儲(chǔ)節(jié)點(diǎn)接收到的最大連續(xù)日志ID，因?yàn)槎鄶?shù)派協(xié)議的使用，每個(gè)存儲(chǔ)節(jié)點(diǎn)的VCL會(huì)不不同。如表1-2所示，沒有表示出S1到S6各個(gè)存儲(chǔ)節(jié)點(diǎn)的VCL，而是只標(biāo)識(shí)出了六個(gè)節(jié)點(diǎn)中所有VCL中的公共最大點(diǎn)，這個(gè)點(diǎn)，是系統(tǒng)故障后恢復(fù)所能恢復(fù)到的一致點(diǎn)。注意依舊不是事務(wù)一致而是Mini事務(wù)一致，存疑的是，不能達(dá)到事務(wù)一致，其意義何在？還有什么重要的細(xì)節(jié)沒有公開嗎？留意到下面這段話，我們可以看出一點(diǎn)端倪（存儲(chǔ)層的恢復(fù)不需要保證事務(wù)一致，存儲(chǔ)層恢復(fù)之后，計(jì)算層還會(huì)繼續(xù)恢復(fù)工作，這樣才能達(dá)到事務(wù)一致）：

However,upon restart, before the database is allowed to access the storage volume, the storage service does its own recovery whichis focused not on user-level transactions, but on making sure thatthe database sees a uniform view of storage despite its distributed nature.

VDL，Volumn Durable LSN，卷持久點(diǎn)：傳統(tǒng)的數(shù)據(jù)庫提供CheckPoint功能，在日志中加入一個(gè)CheckPoint點(diǎn)，作為故障恢復(fù)時(shí)的起始點(diǎn)。VDL就是存儲(chǔ)層的“CheckPoint點(diǎn)”，在VDL之前的日志，已經(jīng)無用可以被GC，但因存儲(chǔ)層的日志一直在持續(xù)不斷地被用于“恢復(fù)”日志為“Caching”中的數(shù)據(jù)頁，所以其作用和原始的“CheckPoint點(diǎn)”相反。注意VDL是所有存儲(chǔ)節(jié)點(diǎn)上的日志比較后得到的一個(gè)共同點(diǎn)，不是一個(gè)Segment級的點(diǎn)，這和VCL相似，都是PG（ProtectionGroup）級別的。其定義如下：

VDL or the Volume Durable LSN as thehighest CPL that is smaller than or equal to VCL and truncate all log recordswith LSN greater than the VDL.

表1-2 日志在主節(jié)點(diǎn)和存儲(chǔ)層的作用表（持久化實(shí)現(xiàn)表）

3.2 事務(wù)與數(shù)據(jù)分布

在1.2節(jié)，我們曾說，目前制約存儲(chǔ)層內(nèi)的“Caching”起更大作用的因素，主要在于分布式事務(wù)的機(jī)制的選取和InnoDB自身的事務(wù)實(shí)現(xiàn)機(jī)制。

這有兩層含義。一是InnoDB自身的事務(wù)實(shí)現(xiàn)機(jī)制制約了存儲(chǔ)層內(nèi)的“Caching”起更大作用。二是分布式事務(wù)的機(jī)制的選取關(guān)聯(lián)著存儲(chǔ)層內(nèi)的“Caching”是否有機(jī)會(huì)起更大作用。

首先：InnoDB的事務(wù)信息，幾乎不在數(shù)據(jù)上（除了元組頭上有個(gè)事務(wù)ID用于版本可見性判斷外再無其他信息），而是位于內(nèi)存中。這其實(shí)是在說，InnoDB的行級鎖即索引項(xiàng)的記錄鎖，其鎖表位于內(nèi)存，不能隨著Aurora的數(shù)據(jù)分布而“分布”。而Oracle的RAC可是在數(shù)據(jù)頁上存儲(chǔ)了足夠多的事務(wù)信息（參見《數(shù)據(jù)庫事務(wù)處理的藝術(shù)事務(wù)管理與并發(fā)控制》一書的第六章），所以RAC中的其他節(jié)點(diǎn)，就能夠隨著被分布的數(shù)據(jù)而獲取事務(wù)相關(guān)的信息從而在分布的各節(jié)點(diǎn)上處理事務(wù)的ACID特性。此點(diǎn)是MySQL能否走向分布式事務(wù)的一個(gè)關(guān)鍵點(diǎn)（當(dāng)然選用不同的分布式事務(wù)實(shí)現(xiàn)機(jī)制會(huì)反過來影響這點(diǎn)結(jié)論）。

其次：分布式事務(wù)的機(jī)制的選取為什么會(huì)影響著Aurora的存儲(chǔ)層內(nèi)的“Caching”是否有機(jī)會(huì)起更大作用呢？

有的分布式事務(wù)架構(gòu)，采取的是集中式架構(gòu)，即中央點(diǎn)總控事務(wù)管理。事務(wù)的決策判斷，都要經(jīng)過中央點(diǎn)進(jìn)行，多個(gè)子節(jié)點(diǎn)需要和中央節(jié)點(diǎn)多次交互。比如PostgreSQL-XC提供了全局事務(wù)管理器。如果MySQL/InnoDB或者Aurora的分布式架構(gòu)向這個(gè)方向發(fā)展，則存儲(chǔ)層內(nèi)的“Caching”就沒有多少機(jī)會(huì)起更大的作用了。

而有的分布式事務(wù)架構(gòu)，采取的是事務(wù)信息隨同存儲(chǔ)分布。這樣不同的節(jié)點(diǎn)就可以進(jìn)行“分布式”的事務(wù)處理。比如基于BigTable的Percolator系統(tǒng)，其核心不在于兩階段提交，而是在于分布的數(shù)據(jù)項(xiàng)上，有著豐富的事務(wù)信息，這些信息足以被任何節(jié)點(diǎn)用于做ACID的實(shí)現(xiàn)判斷（參考《Large-scale Incremental Processing Using Distributed Transactionsand Notifications》）。如果MySQL/InnoDB或者Aurora的分布式架構(gòu)向這個(gè)方向發(fā)展，則存儲(chǔ)層內(nèi)的“Caching”就有很大的機(jī)會(huì)起更大的作用。

走向哪條路，或走向另外的路，需看Aurora的雄心有多大。目前的Aurora告訴我們的是，其分布式架構(gòu)的選擇，僅是用戶數(shù)據(jù)分布。事務(wù)數(shù)據(jù)的分布，其實(shí)是更大的一個(gè)話題。

3.3 事務(wù)處理

MySQL和InnoDB的事務(wù)處理技術(shù)，采用了SS2PL，把強(qiáng)嚴(yán)格兩階段鎖融合到平板事務(wù)模型中，以提交和回滾機(jī)制實(shí)現(xiàn)A特性，并進(jìn)一步在讀數(shù)據(jù)時(shí)加鎖確保C特性，通過MVCC實(shí)現(xiàn)了I特性中的RR和RC隔離級別以提高并發(fā)度。這些技術(shù)，在目前的Aurora中沒有大的改變。如前所述，Aurora改變的是依據(jù)事務(wù)日志做持久化處理（D特性）和系統(tǒng)故障后的恢復(fù)的一部分流程處理（A、C特性的一部分），從整體上看，沒有革命性的變化。但是，Aurora的事務(wù)提交卻是異步的且和VDL相關(guān)（確保持久化），這點(diǎn)在論文中描述很細(xì)致如下：

In Aurora, transaction commits arecompleted asynchronously. When a client commits a transaction, the threadhandling the commit request sets the transaction aside by recording its “commit LSN” as part of aseparate list of transactions waiting on commit and moves on to performother work. The equivalent to the WAL protocol is based on completing a commit,if and only if, the latest VDL is greater than or equal to the transaction’scommit LSN. As the VDL advances, the database identifies qualifyingtransactions that are waiting to be committed and uses a dedicated thread tosend commit acknowledgements to waiting clients. Worker threads do not pausefor commits, they simply pull other pending requests and continueprocessing. ?

???

在1.2節(jié)我們提到“鑒于以上幾點(diǎn)，備機(jī)數(shù)據(jù)獲取和更新的這個(gè)細(xì)節(jié)，算是個(gè)謎”，即備機(jī)的數(shù)據(jù)獲取，是從存儲(chǔ)層而來還是從主節(jié)點(diǎn)而來？我們不妨做個(gè)論文沒有提及的猜想：備機(jī)的數(shù)據(jù)，源自存儲(chǔ)層和主節(jié)點(diǎn)，存儲(chǔ)層統(tǒng)一向上層提供數(shù)據(jù)頁的緩沖服務(wù)，用以不斷響應(yīng)計(jì)算層的數(shù)據(jù)缺頁請求，這起到了傳統(tǒng)的數(shù)據(jù)緩沖區(qū)的作用。而主節(jié)點(diǎn)傳輸日志給備節(jié)點(diǎn)，備節(jié)點(diǎn)可以從中解析出UNDO日志信息（UNDO也是受到REDO的保護(hù)的），從而能夠構(gòu)造出主節(jié)點(diǎn)在某個(gè)時(shí)刻的完整的計(jì)算環(huán)境狀態(tài)（數(shù)據(jù)緩沖區(qū)+UNDO信息），這樣，備機(jī)就可以為接到的讀請求構(gòu)造一致的“ReadView”，為讀操作提供了事務(wù)讀數(shù)據(jù)的一致性狀態(tài)。如為此點(diǎn)，則是一個(gè)巧妙的設(shè)計(jì)。更進(jìn)一步，主機(jī)直接傳輸給備機(jī)的，可以只是準(zhǔn)備寫入REDO的UNDO信息。

3.4 鎖管理

基于MySQL的Aurora同樣使用了基于封鎖的并發(fā)訪問控制技術(shù)。但是，Aurora改造了MySQL的鎖管理器，這點(diǎn)論文沒有提及，而在2017年的Percona技術(shù)大會(huì)上，Aurora的一個(gè)分享展示了如圖1-11的內(nèi)容。圖中顯示，在MySQL的鎖表管理器上，對于Scan、Delete、Insert三種操作，把lock互斥了三種類型的并發(fā)，而Aurora分別按操作類型加鎖“l(fā)ock manager”，提高了并發(fā)度，這樣的鎖，看起來是一個(gè)系統(tǒng)鎖，把一個(gè)粗粒度的系統(tǒng)鎖拆分為三個(gè)細(xì)粒度的系統(tǒng)鎖。但是，較為奇怪的是，如圖1-12，Aurora展示了其效果卻十分的驚人（圖1-13是測試環(huán)境的配置）。

圖1-11 Aurora鎖管理器改進(jìn)圖?

圖1-12 Aurora鎖管理器改進(jìn)后的性能測試對比圖

?

圖1-13 測試環(huán)境配置圖[13]

4 .云服務(wù)能力

4.1 強(qiáng)化的云服務(wù)能力

除了通過更多的數(shù)據(jù)冗余（跨3個(gè)AZ的 6個(gè)副本）提高高可用性外，Aurora還有著其他強(qiáng)大的云服務(wù)能力，這是云數(shù)據(jù)庫需要重點(diǎn)建設(shè)的能力。

存儲(chǔ)方面，存儲(chǔ)的單位是段（segment），每個(gè)段的大小為10G，單實(shí)例數(shù)據(jù)庫存儲(chǔ)最大限是64 TB。

處理系統(tǒng)故障方面：

• 10秒內(nèi)完成一個(gè) 10G的Segment的網(wǎng)絡(luò)遷移。30秒完成故障轉(zhuǎn)移。

• 以Segment為單位周期性并行備份。

• 以REDO日志為單位周期性并行備份。

• 通過日志實(shí)時(shí)地持續(xù)恢復(fù)，提供了更快的crashrecovery。

性能方面：

• 更快的索引構(gòu)建。采用自底向上的索引構(gòu)建方式，比MySQL快２倍到４倍。

• 無鎖并發(fā)Read-View算法。構(gòu)造ReadView采用無鎖算法減少競爭提高性能。

• 無鎖隊(duì)列提高審計(jì)功能的速度。

• 其他如熱行競爭、批量數(shù)據(jù)插入等性能提升明顯。

其他云服務(wù)：

• 提供快速 provisioning 和部署。

• 自動(dòng)安裝補(bǔ)丁和軟件升級。

• 備份和 point-in-time 恢復(fù)。

• 計(jì)算和存儲(chǔ)的擴(kuò)展性支持。

如圖1-3所示，存儲(chǔ)系統(tǒng)的元數(shù)據(jù)存于Amazon DynamoDB中，使用Amazon SWF提供的工作流實(shí)現(xiàn)對Aurora的自動(dòng)化管理，這也是云中規(guī)模化服務(wù)的重要能力。

萬能數(shù)據(jù)庫

AWS的Aurora不只是MySQL的一個(gè)分支版本，更像是一個(gè)萬能的數(shù)據(jù)庫系統(tǒng)，這樣的系統(tǒng)，通過兼容各種主流數(shù)據(jù)庫的SQL語法、功能，也許能在云上一統(tǒng)數(shù)據(jù)庫的服務(wù)，把各種數(shù)據(jù)庫的用戶應(yīng)用接入，通過統(tǒng)一的一個(gè)分布式的數(shù)據(jù)庫引擎，提供各種數(shù)據(jù)庫的數(shù)據(jù)服務(wù)能力。

AWS的官網(wǎng)，聲明了“兼容 PostgreSQL的Amazon Aurora”如下：

AmazonRelational Database Service (Amazon RDS) 正在提供 Aurora(PostgreSQL) 預(yù)覽版，即兼容 PostgreSQL 的 Amazon Aurora。Aurora 是一種完全托管的、兼容 PostgreSQL 和 MySQL 的關(guān)系數(shù)據(jù)庫引擎。

單從字面看，Aurora不再是MySQL，而是MySQL+PostgreSQL，所以將來將會(huì)是 “MySQL+PostgreSQL+...+...”，各種數(shù)據(jù)庫都將融于Aurora當(dāng)中。這樣提供強(qiáng)大無比的云數(shù)據(jù)庫服務(wù)，此點(diǎn)非常重要，用戶基于任何數(shù)據(jù)庫的應(yīng)用均不用修改應(yīng)用的代碼，無縫接入Aurora。

從技術(shù)的層面看，實(shí)現(xiàn)這樣的目標(biāo)，有多種方式。簡單的方式，就是利用相同的云基礎(chǔ)設(shè)施和云服務(wù)概念，把各個(gè)數(shù)據(jù)庫單獨(dú)云化，然后用Aurora統(tǒng)一命名。但如果進(jìn)一步把計(jì)算層分離，如把語法解析、查詢器、執(zhí)行器拆分，不同種類的數(shù)據(jù)庫使用各自的語法解析和查詢優(yōu)化，然后統(tǒng)一執(zhí)行計(jì)劃交給統(tǒng)一的執(zhí)行器去執(zhí)行，事務(wù)處理和數(shù)據(jù)存儲(chǔ)則可以獨(dú)自研發(fā)獨(dú)立于上層的計(jì)算。如此，想象空間得以打開......

5. 小結(jié)

本文探討了Aurora的實(shí)現(xiàn)方面的技術(shù)內(nèi)容，由于作者水平有限，錯(cuò)漏之處，請不吝指正。Aurora在實(shí)現(xiàn)方面的諸多細(xì)節(jié)，論文并沒有提及，期待以此文拋磚引玉，期待多方指點(diǎn)討論，共同進(jìn)步。

附錄

參考資料:

1. ?《Amazon Aurora: Design Considerations for High Throughput CloudNative Relational Databases》

2. ?https://aws.amazon.com/

3. ?《數(shù)據(jù)庫事務(wù)處理的藝術(shù)事務(wù)管理與并發(fā)控制》，機(jī)械工業(yè)出版社，2017年10月出版

4. ?Aurora deep dive - Percona Live 2017

5. ?https://aws.amazon.com/tw/blogs/database/category/aurora/?nc1=h_l

6. ?《High performance transactions in deuteronomy》

轉(zhuǎn)載聲明：文章為2017年7月《程序員》原創(chuàng)，本公眾號已獲轉(zhuǎn)載授權(quán)。

總結(jié)

以上是生活随笔為你收集整理的Amazon Aurora 深度探索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。