NineData 聯(lián)合創(chuàng)始人周振興（蘇普）受邀參加2023年 ACMUG 第一站西安站，發(fā)表了《云數(shù)據(jù)庫(kù)架構(gòu)與選型》主題演講。

ACMUG，全稱為中國(guó)MySQL用戶組 (All China MySQL User Group) ，是 MySQL 和 MariaDB 在中國(guó)最大的技術(shù)社區(qū)，是得到了 Oracle User Group Community、MairaDB Foundation、中國(guó)計(jì)算機(jī)行業(yè)協(xié)會(huì)開(kāi)源數(shù)據(jù)庫(kù)專業(yè)委員會(huì)等官方認(rèn)可的社區(qū)組織，ACMUG 會(huì)邀請(qǐng)國(guó)內(nèi)外頂尖互聯(lián)網(wǎng)公司和大型企業(yè)技術(shù)專家，分享其在數(shù)據(jù)庫(kù)、大數(shù)據(jù)、云原生、AIOps 等技術(shù)方向上的經(jīng)驗(yàn)以及最新進(jìn)展。

以下內(nèi)容，根據(jù)周振興在【2023年 ACMUG 第一站西安站 】線下演講內(nèi)容整理而成。

AWS 在 2009 年發(fā)布第一款云數(shù)據(jù)庫(kù)產(chǎn)品 RDS MySQL，阿里云于2011年 也發(fā)布了自己的 RDS MySQL，到現(xiàn)在，云數(shù)據(jù)庫(kù)技術(shù)已經(jīng)經(jīng)過(guò)了 14 年的發(fā)展。云數(shù)據(jù)庫(kù)的架構(gòu)已經(jīng)變得非常復(fù)雜，上周則借著 ACMUG（中國(guó) MySQL 用戶組）的分享則總結(jié)了 AWS 和阿里云 RDS 的主要架構(gòu)特點(diǎn)，并通過(guò)一張架構(gòu)圖匯總，幫助開(kāi)發(fā)者根據(jù)需要在合適的場(chǎng)景選擇合適的架構(gòu)與規(guī)格。

一、AWS：選擇合適的 RDS 架構(gòu)與規(guī)格

1.1 架構(gòu)與規(guī)格大圖

該架構(gòu)圖包含了高可用架構(gòu)、CPU 架構(gòu)選擇、存儲(chǔ)類型選擇等內(nèi)容。該架構(gòu)圖不包括性能、精確的對(duì)應(yīng)關(guān)系（如 SQL Server 支持的存儲(chǔ)空間大小與 MySQL 有什么差別）等內(nèi)容，暫時(shí)不包括 Aurora 架構(gòu)（后續(xù)考慮補(bǔ)充）、Custom、Outpost 類型等。

1.2 高可用架構(gòu)

AWS RDS 的高可用架構(gòu)包括了單可用區(qū)（Single-AZ / Single DB instance）、多可用區(qū)（Multi-AZ DB instance）這兩種常見(jiàn)類型，RDS MySQL/PostgreSQL 還提供了多可用區(qū)集群版（Multi-AZ DB Cluster）。

1.2.1 單/多可用區(qū)

該選項(xiàng)清晰的描述了實(shí)例的在可用區(qū)級(jí)別的容災(zāi)能力：

單可用區(qū)版本的數(shù)據(jù)庫(kù)僅一個(gè)實(shí)例，沒(méi)有高可用節(jié)點(diǎn)，如果節(jié)點(diǎn)失敗，則會(huì)重啟主機(jī)或者使用新的節(jié)點(diǎn)，整個(gè)過(guò)程會(huì)比較長(zhǎng)。

多可用區(qū)版本，則默認(rèn)會(huì)使用兩個(gè)節(jié)點(diǎn)，且一定分布在兩個(gè)不同的可用區(qū)，實(shí)例可以實(shí)現(xiàn)跨可用區(qū)的容災(zāi)。當(dāng)一個(gè)可用區(qū)出現(xiàn)故障的時(shí)候，實(shí)例會(huì)發(fā)生切換，容災(zāi)到另一個(gè)可用區(qū)。AWS 的多可用區(qū)版本，主備之間使用的是存儲(chǔ)層（EBS）的物理復(fù)制，所以因此其性能也會(huì)受到一定的限制。

1.2.2 多可用區(qū)集群版

這是 Amazon RDS 在去年發(fā)布新的架構(gòu)形態(tài)，詳細(xì)參考：AWS RDS 發(fā)布三節(jié)點(diǎn)形態(tài)，哪些業(yè)務(wù)場(chǎng)景應(yīng)該選擇？。該形態(tài)主要解決原來(lái)的“多可用區(qū)版本”備節(jié)點(diǎn)完全不可用（相對(duì)成本較高）的問(wèn)題。

“多可用區(qū)集群版”使用了數(shù)據(jù)庫(kù)的類似的半同步復(fù)制機(jī)制（參考系統(tǒng)參數(shù)判斷出來(lái)的），數(shù)據(jù)庫(kù)的事務(wù)寫入需要至少兩個(gè)（多數(shù)派）寫入成功才成功，但因?yàn)橛袃蓚€(gè)備節(jié)點(diǎn)，所以相比“多可用區(qū)版本”性能會(huì)更好，另外，因?yàn)槭菙?shù)據(jù)庫(kù)層的復(fù)制，而不是塊級(jí)別，寫入和同步路徑會(huì)更短，也會(huì)讓延遲更低一些。

該版本，似乎是當(dāng)前 Amaozn RDS 主推的版本（從 RDS 創(chuàng)建流程中的默認(rèn)選項(xiàng)和選項(xiàng)順序來(lái)看）。

當(dāng)前，多可用區(qū)集群版是標(biāo)準(zhǔn)模板中的第一個(gè)、也是默認(rèn)選項(xiàng)。

關(guān)于該版本的架構(gòu)、優(yōu)缺點(diǎn)等相關(guān)信息可以參考該文章獲得更多詳細(xì)內(nèi)容：AWS RDS 發(fā)布三節(jié)點(diǎn)形態(tài)，哪些業(yè)務(wù)場(chǎng)景應(yīng)該選擇？

1.3 CPU 架構(gòu)

主流的云廠商都逐步開(kāi)始提供 X86 和 ARM 架構(gòu)的 CPU，AWS 在這方面是在這方面動(dòng)作最早的。在2018年 re:Invent 上推出了第一代的 Graviton，2019年推出了 Graviton 2，2021年推出了 Graviton 3。可以認(rèn)為，當(dāng)前產(chǎn)品已經(jīng)有一定的成熟度，根據(jù) Percona 做的 MySQL 測(cè)試，我們也看到，Graviton 在不同的并發(fā)類型，都表現(xiàn)出了與 Intel X86 差不多的性能，并且在高并發(fā)（并發(fā)數(shù)超過(guò) CPU 核心數(shù)量）時(shí)，Graviton 表現(xiàn)還要更好一些。

性能比較接近，成本又更低，所以，目前已經(jīng)有不少客戶在嘗試通過(guò) Graviton 實(shí)例降低成本。目前，AWS RDS 也有非常多的 Graviton 的規(guī)格供選擇。

當(dāng)前的建議是：可以考慮在部分業(yè)務(wù)中嘗試使用 Graviton 降低成本，根據(jù)企業(yè)內(nèi)部的負(fù)載情況，再逐步考慮擴(kuò)大范圍使用。

另外，值得一提的是，AWS RDS 提供的最大規(guī)格是 db.x2iedn.32xlarge，具備 128vCPU 4096GB，一般來(lái)說(shuō)，企業(yè)內(nèi)部絕絕大多數(shù)業(yè)務(wù)都是滿足需要的。

1.4 存儲(chǔ)層

接著來(lái)看看 AWS RDS 提供了哪些存儲(chǔ)類型。

AWS RDS 當(dāng)前主流的存儲(chǔ)類型包括了 gp2、gp3、io1（預(yù)留 IOPS 的 SSD），以及一個(gè)已經(jīng)過(guò)時(shí)的 HDD 存儲(chǔ)。其中：

gp2 存儲(chǔ)定位是適用于開(kāi)發(fā)測(cè)試環(huán)境，存儲(chǔ)大小最大為64TB，最大 IOPS 為64000。在購(gòu)買時(shí)，只能選定存儲(chǔ)空間，其 IOPS 會(huì)根據(jù)存儲(chǔ)空間進(jìn)行換算，一般的會(huì)是存儲(chǔ)空間的三倍，但是有一個(gè)下限、也有64000的上限。

gp3 定位是生產(chǎn)環(huán)境的 OLTP 應(yīng)用，gp3 的最大存儲(chǔ)空間和gp2相同，但是，gp3 存儲(chǔ)可以單獨(dú)購(gòu)買 IOPS，即存儲(chǔ)空間和 IOPS 是可以分開(kāi)購(gòu)買的，這就給用戶提供了更大的靈活度。但是，需要注意的是 IOPS 購(gòu)買的上限/下限也與存儲(chǔ)有一定的關(guān)系。避免了，購(gòu)買非常小的存儲(chǔ)空間，但是購(gòu)買非常大的 IOPS 的情況。具體的限制可以參考其文檔介紹。所以，gp3 類型的實(shí)例，其計(jì)費(fèi)也是按照存儲(chǔ)空間和 IOPS 分開(kāi)計(jì)費(fèi)的。

gp2、gp3 存儲(chǔ)所提供的 SLA 都是99%的請(qǐng)求在毫秒級(jí)別。

io1（預(yù)留 IOPS 的 SSD）則提供了更高性能的存儲(chǔ)，最大存儲(chǔ)空間依舊是64TB，但是其 IOPS 則可以高達(dá)25.6萬(wàn)。另外，io1 存儲(chǔ)提供的 SLA 也更高，為99.9%的請(qǐng)求在毫秒級(jí)別。計(jì)費(fèi)也是按照存儲(chǔ)空間和 IOPS 分開(kāi)計(jì)費(fèi)。

HDD 存儲(chǔ)是過(guò)時(shí)的存儲(chǔ)類型，主要為了保持兼容性而存在，其最大存儲(chǔ)空間為3TB、最大 IOPS 為1000。

在實(shí)際的選擇中，開(kāi)發(fā)測(cè)試環(huán)境則可以使用 gp2 類型、一般業(yè)務(wù)使用 gp3 類型，對(duì)于核心業(yè)務(wù)則可以使用 io1 類型。

1.5 規(guī)格代碼

關(guān)于規(guī)格代碼，國(guó)內(nèi)的云廠商一般不是太強(qiáng)調(diào)，也不是太關(guān)注。但是 AWS 因?yàn)槠湟?guī)格代碼非常規(guī)范，也非常簡(jiǎn)潔，所傳達(dá)的含義也比較準(zhǔn)確，所以很多時(shí)候，在提及規(guī)格時(shí)，大家會(huì)使用其規(guī)格代碼，而不是使用 vcpu 數(shù)量和內(nèi)存大小。

例如，db.m6gd.16xlarge，則可以知道這是一個(gè)數(shù)據(jù)庫(kù)實(shí)例，64vCPU，256GB內(nèi)存，并且為 Graviton 架構(gòu)的第六代（Graviton 2）實(shí)例，并且在本地具備額外的 NVMe SSD。

規(guī)格代碼中的“db”代表了這是一個(gè)用于數(shù)據(jù)庫(kù)的實(shí)例（ec2）；

{t|m|r|x}分別代表了突發(fā)型實(shí)例 t（小規(guī)格）、標(biāo)準(zhǔn)實(shí)例 m（內(nèi)存 cpu 比為4）、內(nèi)存優(yōu)化型 r（內(nèi)存 cpu 比為8）、內(nèi)存優(yōu)化型 x（內(nèi)存 cpu 比為16）；

跟在其后的，則是 CPU 的迭代；

數(shù)字之后的可能出現(xiàn)的字母包括：g、d、n、i等。g代表這是一個(gè) Graviton 類型的實(shí)例、d 代表該實(shí)例本地有額外的、增強(qiáng)的存儲(chǔ)資源、n則代表了額外的網(wǎng)絡(luò)能力、i 代表這是一個(gè) Intel X86 架構(gòu)的實(shí)例。

1.6 其他

1.6.1 關(guān)于“可用區(qū)”

可用區(qū)可以理解為一片機(jī)房區(qū)域。例如，在東京東部的某個(gè)機(jī)房區(qū)域，通常會(huì)有數(shù)棟?rùn)C(jī)房。一個(gè)大區(qū)域（Region，例如東京）會(huì)有多個(gè)可用區(qū)。

1.6.2 補(bǔ)充說(shuō)明

本文內(nèi)容主要聚焦于使用最多的各個(gè)云廠商的 RDS 數(shù)據(jù)庫(kù)的架構(gòu)與選型，并不包括完整的產(chǎn)品系列；

該架構(gòu)圖旨在幫助大家從整體框架上了解云數(shù)據(jù)庫(kù)整體概括，并不是精確的架構(gòu)圖，并不求精確、面面俱到，例如 RDS MySQL、RDS SQL Server在很多細(xì)節(jié)上是不同的，這里并沒(méi)有體現(xiàn)，這些詳情可以參考各個(gè)云廠商的相關(guān)文檔；

這里不包括價(jià)格、性能相關(guān)的內(nèi)容。

二、阿里云：選擇合適的 RDS 架構(gòu)與規(guī)格

2.1 架構(gòu)與規(guī)格大圖

一張圖讀懂阿里云數(shù)據(jù)庫(kù) RDS 架構(gòu)與選型

在 v1 版本發(fā)布的時(shí)候，詳細(xì)的介紹了阿里云數(shù)據(jù)庫(kù) RDS 主要架構(gòu)類型、資源復(fù)用與規(guī)格、數(shù)據(jù)庫(kù)專屬集群、本地盤與云盤版、通用型與獨(dú)享型、超配比等內(nèi)容，這里不再贅述，如果感興趣可以參考：一張圖讀懂阿里云數(shù)據(jù)庫(kù)架構(gòu)與選型。

2.2 主要的架構(gòu)類型

數(shù)據(jù)庫(kù)通常是企業(yè)業(yè)務(wù)架構(gòu)中的核心組件，數(shù)據(jù)庫(kù)的可用性與業(yè)務(wù)可用性直接相關(guān)。所以，高可用是云數(shù)據(jù)庫(kù)架構(gòu)選型第一個(gè)需要關(guān)注的內(nèi)容。

從高可用角度，阿里云數(shù)據(jù)庫(kù)提供了基礎(chǔ)版（即單節(jié)點(diǎn)）、雙節(jié)點(diǎn)高可用版、三節(jié)點(diǎn)企業(yè)版。不同的版本，則是在成本、可用性、數(shù)據(jù)可靠性之間的平衡：

單節(jié)點(diǎn)通過(guò)簡(jiǎn)單的架構(gòu)，以最低的成本提供了基本可用的云數(shù)據(jù)庫(kù)服務(wù)；

雙節(jié)點(diǎn)高可用版則是適合絕大多數(shù)業(yè)務(wù)場(chǎng)景的模式，兩個(gè)節(jié)點(diǎn)分布于一個(gè)地區(qū)的兩個(gè)可用區(qū)，故障時(shí)，切換速度較快，數(shù)據(jù)雙副本，可靠性也比較高；

三節(jié)點(diǎn)企業(yè)版，則通過(guò) X-Paxos 實(shí)現(xiàn)底層數(shù)據(jù)一致，并以三副本（兩份數(shù)據(jù)+一份日志）保障數(shù)據(jù)可靠性。

2.2.1 基礎(chǔ)版（即單節(jié)點(diǎn)版本）

阿里云基礎(chǔ)版使用阿里云云盤作為數(shù)據(jù)庫(kù)存儲(chǔ)，掛載在數(shù)據(jù)庫(kù)的計(jì)算節(jié)點(diǎn)上，實(shí)現(xiàn)了存儲(chǔ)與計(jì)算的分離。這使得，計(jì)算節(jié)點(diǎn)出現(xiàn)故障的時(shí)候，重新使用一個(gè)新的計(jì)算節(jié)點(diǎn)，再重新掛載原來(lái)的數(shù)據(jù)庫(kù)存儲(chǔ)，即可啟動(dòng)數(shù)據(jù)庫(kù)，恢復(fù)出現(xiàn)故障的數(shù)據(jù)庫(kù)。所以，在計(jì)算節(jié)點(diǎn)發(fā)生故障的時(shí)候，RPO 通常小于1分鐘，RTO 則為5分鐘~一小時(shí)。當(dāng)整個(gè)可用區(qū)發(fā)生故障的時(shí)候，RPO 和 RTO 的值則依賴數(shù)據(jù)庫(kù)備份的頻率情況。

2.2.2 高可用版

兩節(jié)點(diǎn)高可用是用戶使用最多的版本，也是數(shù)據(jù)庫(kù)最為常見(jiàn)的架構(gòu)。數(shù)據(jù)庫(kù)由主備兩個(gè)節(jié)點(diǎn)組成，通過(guò)數(shù)據(jù)庫(kù)層的邏輯日志進(jìn)行復(fù)制。相比單節(jié)點(diǎn)，無(wú)論是在數(shù)據(jù)可靠性、服務(wù)的可用性都有非常大的提升。由于主備節(jié)點(diǎn)都在同一個(gè)大 region，日志延遲通常都非常小，所以發(fā)生單節(jié)點(diǎn)故障時(shí)，高可用版的數(shù)據(jù)可靠性通常是比較高的。注意到，AWS 對(duì)應(yīng)的雙節(jié)點(diǎn)版本的 RPO 是零，那么阿里云數(shù)據(jù)庫(kù)怎樣呢？

具體的，對(duì)阿里云 RDS MySQL，阿里云的兩節(jié)點(diǎn)高可用，根據(jù)所選擇的參數(shù)模板分為如下三類：

高性能：sync_binlog=1000, innodb_flush_log_at_trx_commit=2, async；

異步模式：sync_binlog=1, innodb_flush_log_at_trx_commit=1, async；

默認(rèn)：sync_binlog=1, innodb_flush_log_at_trx_commit=1, semi-sync。

其中，“高性能”版本和“異步”版本，都是異步復(fù)制，在發(fā)生主節(jié)點(diǎn)故障時(shí)，因?yàn)閺?fù)制為異步的，可能會(huì)有少部分的事務(wù)日志沒(méi)有傳到備節(jié)點(diǎn)，則可能會(huì)丟失少部分事務(wù)。也就是說(shuō)，這兩個(gè)版本為了實(shí)現(xiàn)更好的性能，在數(shù)據(jù)庫(kù)的 RPO 上做了小的讓步?！澳J(rèn)”版本，使用了半同步復(fù)制，通常，數(shù)據(jù)可靠性會(huì)更高。但因?yàn)榘胪娇赡軙?huì)有退化的場(chǎng)景，所以，該模式下數(shù)據(jù)復(fù)制還是在極端的情況下，還會(huì)有數(shù)據(jù)丟失的可能性。

那么，既然“異步”模式和“高性能”都有數(shù)據(jù)丟失的風(fēng)險(xiǎn)，他們的區(qū)別是什么什么呢？簡(jiǎn)單的概括，“異步”產(chǎn)生微小數(shù)據(jù)丟失的可能性更小。因?yàn)椋鱾涔?jié)點(diǎn)通過(guò)設(shè)置sync_binlog=1,
innodb_flush_log_at_trx_commit=1，可以最大可能性的保障，主節(jié)點(diǎn)的數(shù)據(jù)可靠性。

事實(shí)上，高可用版本是可以滿足絕大多數(shù)業(yè)務(wù)場(chǎng)景的需要的，一方面同一個(gè)可用區(qū)內(nèi)數(shù)據(jù)傳輸延遲非常小，日志傳輸通常都非常通暢，即便主節(jié)點(diǎn)發(fā)生故障，實(shí)際的情況中，通常不會(huì)出現(xiàn)日志延遲。另外，主節(jié)點(diǎn)失敗后，通?？梢酝ㄟ^(guò)重啟等方式恢復(fù)，云廠商的硬件都有著較為標(biāo)準(zhǔn)的硬件過(guò)保淘汰的機(jī)制，硬件完全不可用的情況也并不多。另外，底層磁盤會(huì)通過(guò)硬 RAID 或者軟 RAID 的方式，保障磁盤數(shù)據(jù)存儲(chǔ)的可靠性，數(shù)據(jù)即便是在一臺(tái)機(jī)器上，也會(huì)保存在兩塊盤上。

兩節(jié)點(diǎn)高可用版本在某些特殊場(chǎng)景下，數(shù)據(jù)還是存在一些不可用風(fēng)險(xiǎn)，例如，當(dāng)其中一個(gè)節(jié)點(diǎn)發(fā)生故障，而本地?cái)?shù)據(jù)量又非常大時(shí)，需要重新在一臺(tái)新的機(jī)器上搭建備節(jié)點(diǎn)時(shí)，因?yàn)閿?shù)據(jù)量較大，重建時(shí)間通常會(huì)比較長(zhǎng)，而這時(shí)候，主節(jié)點(diǎn)則會(huì)一直單節(jié)點(diǎn)運(yùn)行，如果不幸主節(jié)點(diǎn)再出現(xiàn)故障，則會(huì)出現(xiàn)不可用或者數(shù)據(jù)丟失。如果，對(duì)數(shù)據(jù)的安全性有更高的要求，則可以考慮選擇“三節(jié)點(diǎn)企業(yè)版”。

2.2.3 三節(jié)點(diǎn)企業(yè)版

當(dāng)前僅 RDS MySQL 有該版本。三節(jié)點(diǎn)企業(yè)版使用了基于 X-Paxos[^4] 的一致性協(xié)議實(shí)現(xiàn)了數(shù)據(jù)的同步復(fù)制，適用于數(shù)據(jù)安全可靠性要求非常高的場(chǎng)景，例如金融交易數(shù)據(jù)等。三節(jié)點(diǎn)中，有一個(gè)節(jié)點(diǎn)僅存儲(chǔ)日志，以此實(shí)現(xiàn)接近于兩個(gè)節(jié)點(diǎn)的成本與價(jià)格，實(shí)現(xiàn)更高的數(shù)據(jù)安全與可靠性。

三節(jié)點(diǎn)企業(yè)版在創(chuàng)建的時(shí)候，可以選擇分布在1~3個(gè)可用區(qū)。如果需要跨可用區(qū)的容災(zāi)，則可以讓三個(gè)副本分布于三個(gè)可用區(qū)，如果需要更高的性能，則可以讓三個(gè)副本都在同一個(gè)可用區(qū)。

2.2.4 關(guān)于MySQL的參數(shù)sync_binlog, innodb_flush_log_at_trx_commit

在阿里云 RDS 的高可用參數(shù)模板選擇中，不同的參數(shù)模板，最主要的區(qū)別就是這兩個(gè)參數(shù)的不同配置。這是 MySQL 和 InnoDB 在數(shù)據(jù)安全性上最重要的兩個(gè)參數(shù)。雙1設(shè)置（sync_binlog=1,
innodb_flush_log_at_trx_commit=1）是數(shù)據(jù)安全性最高的配置。

數(shù)據(jù)庫(kù)是日志先行（WAL）的系統(tǒng)，通過(guò)事務(wù)日志的持久化存儲(chǔ)來(lái)保障數(shù)據(jù)的持久化。在一般的 Linux 系統(tǒng)中，數(shù)據(jù)寫入磁盤的持久化需要通過(guò)系統(tǒng)調(diào)用 fsync 來(lái)完成，相對(duì)于內(nèi)存操作，fsync 需要將數(shù)據(jù)寫入磁盤，這是一個(gè)非常“耗時(shí)”的操作。而上面這兩個(gè)參數(shù)就是控制 MySQL 的二進(jìn)制日志和 InnoDB 的日志何時(shí)調(diào)用 fsync 完成數(shù)據(jù)的持久化。所以，這兩個(gè)參數(shù)的配置很大程度上反映了 MySQL 在性能與安全性方面的平衡。

其中，sync_binlog 代表了，MySQL 層的日志（即二進(jìn)制日志）的刷寫磁盤的頻率，如果設(shè)置成 1，則代表每個(gè)二進(jìn)制日志寫入文件后，都會(huì)進(jìn)行強(qiáng)制刷盤。如果設(shè)置成 0，則代表 MySQL 自己不會(huì)強(qiáng)制要求操作系統(tǒng)將緩存刷入磁盤，而由操作系統(tǒng)自己來(lái)控制這個(gè)行為。如果設(shè)置成其他的數(shù)字 N，則代表完成N個(gè)二進(jìn)制日志寫入后，則進(jìn)行一次刷寫數(shù)據(jù)的系統(tǒng)調(diào)用。

innodb_flush_log_at_trx_commit 則控制了 InnoDB 的日志刷寫磁盤的頻率。取值可以是 0,1,2。

其中 1 最嚴(yán)格，代表每個(gè)事務(wù)完成后都會(huì)刷寫到磁盤中。

如果該參數(shù)設(shè)置成 0，那么在事務(wù)完成后，InnoDB并不會(huì)立刻調(diào)用文件系統(tǒng)寫入操作也不會(huì)調(diào)用磁盤刷寫操作，而是每隔1秒才調(diào)用一次文件系統(tǒng)寫入操作和磁盤刷寫操作。那么，在操作系統(tǒng)崩潰的情況下，可能會(huì)丟失1秒的事務(wù)。

如果該參數(shù)設(shè)置成 2，那么，每次 InnoDB 事務(wù)完成的時(shí)候，都會(huì)通過(guò)系統(tǒng)調(diào)用 write 將數(shù)據(jù)寫入文件（這時(shí)候可能只是寫入到了文件系統(tǒng)的緩存，而不是磁盤），但是每隔1秒才會(huì)進(jìn)行一次刷寫到磁盤的操作。那么，在操作系統(tǒng)崩潰的情況下，可能會(huì)丟失1秒的事務(wù)。相比設(shè)置成 0，該設(shè)置會(huì)讓 InnoDB 更加頻繁地調(diào)用文件系統(tǒng)寫入操作，數(shù)據(jù)的安全性要比設(shè)置成 0 高一些。

我們可以通過(guò)下圖來(lái)理解這兩個(gè)參數(shù)的含義，以及在操作系統(tǒng)中對(duì)應(yīng)的“寫入文件系統(tǒng)”與“刷寫數(shù)據(jù)到磁盤”的含義。首先，在數(shù)據(jù)庫(kù)的事務(wù)處理過(guò)程中，會(huì)產(chǎn)生 binlog 日志和 InnoDB 的 redo 日志，這兩個(gè)日志分別在 MySQL Server 層面和 InnoDB 引擎層面保障了事務(wù)的持久性。在事務(wù)提交的時(shí)候，數(shù)據(jù)庫(kù)會(huì)先將數(shù)據(jù)“寫入文件系統(tǒng)”，通常文件系統(tǒng)會(huì)先將數(shù)據(jù)寫入文件緩存中，該緩存是在內(nèi)存中，這樣就意味著，如果發(fā)生操作系統(tǒng)級(jí)別的宕機(jī)，那么寫入的日志就會(huì)丟失。為了避免這種數(shù)據(jù)丟失，數(shù)據(jù)庫(kù)接著會(huì)通過(guò)系統(tǒng)調(diào)用，“刷寫數(shù)據(jù)到磁盤”中。此時(shí)，即可以認(rèn)為數(shù)據(jù)已經(jīng)持久化到磁盤中。

這時(shí)，再回頭看看阿里云 RDS 的參數(shù)模板。在高性能模板中，”sync_binlog=1000,
innodb_flush_log_at_trx_commit=2, async”，代表了在寫入1000個(gè) binlog 日志后再進(jìn)行刷寫數(shù)據(jù)到磁盤的操作，InnoDB 的日志則都會(huì)先寫入文件系統(tǒng)，然后每隔一秒進(jìn)行一次刷寫數(shù)據(jù)到磁盤。在“默認(rèn)模式下，“默認(rèn)：sync_binlog=1, innodb_flush_log_at_trx_commit=1, semi-sync”，則是最嚴(yán)格的日志模式，也就是會(huì)保障每個(gè)事務(wù)日志安全的刷寫到磁盤。

日志的刷寫模式對(duì)性能有非常大的影響。如果不去關(guān)注這些參數(shù)，就直接去測(cè)試不同云廠商的性能，則會(huì)發(fā)現(xiàn)，云廠商之間的 RDS 有著非常大的性能差異。通常，這些差異并不是廠商之前的技術(shù)能力導(dǎo)致的，更多的是由于他們?cè)趯?duì)于安全性和性能的平衡時(shí)，選擇的不同的平衡點(diǎn)。

2.3 資源復(fù)用與規(guī)格

從資源共享與隔離上，RDS 又分為：通用型、獨(dú)享型和共享型。具體的：

“通用型”適合一般的業(yè)務(wù)使用場(chǎng)景，但有一定的 CPU 共享率，也就說(shuō)是，有一定的概率實(shí)例的資源可能會(huì)被其他實(shí)例爭(zhēng)搶而導(dǎo)致性能的波動(dòng) 。

“獨(dú)享型”則使用完全獨(dú)享的 CPU 的資源和內(nèi)存資源，不會(huì)共享其他人的資源，自己的資源也不會(huì)被其他人共享，所以，有更穩(wěn)定的性能。

“共享型”則與通用型類似 CPU 資源會(huì)被共享，并且共享率更高，所以性價(jià)比更高，同時(shí)受到資源爭(zhēng)搶的影響的可能性也更大，當(dāng)前僅 SQL Server 支持。

除了，上述主要規(guī)格類型之外，阿里云還提供了“獨(dú)占物理機(jī)”規(guī)格，選擇該規(guī)格的用戶可以完全的獨(dú)占一臺(tái)物理機(jī)的資源：

2.4 數(shù)據(jù)庫(kù)專屬集群 MyBase

專屬集群 MyBase 是阿里云推出的一種特殊的形態(tài)。可以理解為，是一種全托管 RDS 與自建數(shù)據(jù)庫(kù)的中間形態(tài)。在全托管的 RDS 基礎(chǔ)上，提供了兩個(gè)重大的能力：

允許用戶登錄數(shù)據(jù)庫(kù)所在的主機(jī)；

允許用戶配置數(shù)據(jù)庫(kù)實(shí)例 CPU 的“超配比”。

當(dāng)然，要求是用戶一次購(gòu)買一個(gè)非常大的、可以容納多個(gè) RDS 實(shí)例的“大集群”，專屬集群則提供了以上兩個(gè)能力，以及 RDS 其他的基本能力，包括安裝配置、監(jiān)控管理、備份恢復(fù)等一系列生命周期管理能力。

使用這種規(guī)格，用戶具備更大的自由度。一方面可以登錄主機(jī)，觀測(cè)主機(jī)與數(shù)據(jù)庫(kù)的狀態(tài)，或者將自己原有的監(jiān)控體系部署到專屬集群中。另一方面，用戶可以根據(jù)自己的業(yè)務(wù)特點(diǎn)，控制集群內(nèi)的 CPU 資源的超配比。對(duì)于核心的應(yīng)用，則使用資源完全不超配的集群；對(duì)于響應(yīng)時(shí)間沒(méi)有那么敏感的應(yīng)用，例如開(kāi)發(fā)測(cè)試環(huán)境，則可以配置高達(dá) 300% 的 CPU 超配比，以此大大降低數(shù)據(jù)庫(kù)的成本。

2.5 關(guān)于本地盤與云盤版

阿里云的主要版本都會(huì)支持本地 SSD 和高性能云盤。他們的差異在于計(jì)算節(jié)點(diǎn)與磁盤存儲(chǔ)是否在同一臺(tái)物理機(jī)器上，對(duì)于使用高性能云盤的規(guī)格，通常是通過(guò)掛載一個(gè)同地區(qū)的網(wǎng)絡(luò)塊設(shè)備作為存儲(chǔ)。

對(duì)于阿里云廠商來(lái)說(shuō)，未來(lái)主推的將是云盤版。原因是云盤相對(duì)于本地盤來(lái)說(shuō)，有很多的優(yōu)勢(shì)：

統(tǒng)一使用云盤版，讓云廠商的供應(yīng)鏈管理變得簡(jiǎn)單。如果使用本地盤版本，意味著數(shù)據(jù)庫(kù)機(jī)型定制性會(huì)增強(qiáng)，供應(yīng)鏈的困難會(huì)增加產(chǎn)品的成本，最終影響價(jià)格。另外，簡(jiǎn)單的供應(yīng)鏈也會(huì)讓產(chǎn)品的部署更加標(biāo)準(zhǔn)化，更加敏捷地實(shí)現(xiàn)多環(huán)境多區(qū)域的部署。

使用云盤版，也可以理解為是“存儲(chǔ)計(jì)算分離”的架構(gòu)，那么如果計(jì)算節(jié)點(diǎn)故障，則可以快速通過(guò)使用一臺(tái)新的計(jì)算節(jié)點(diǎn)并掛載云盤，而實(shí)現(xiàn)高可用。這種方式有著非常好的通用性，無(wú)論是哪種數(shù)據(jù)庫(kù)都可以使用，而無(wú)需考慮數(shù)據(jù)庫(kù)種類之間的差異。無(wú)論是 MySQL 還是 PostgreSQL、Oracle 都可以使用這種方式實(shí)現(xiàn)高可用。

云盤版本身提供了一定的高可用與高可靠能力。云盤本身數(shù)據(jù)可以通過(guò) RAID 或者 EC 算法實(shí)現(xiàn)數(shù)據(jù)的冗余與高可用，并且可以將數(shù)據(jù)分片到不同的磁盤與機(jī)器上，整體的吞吐會(huì)更高。

云盤版本身是分布式的，可以提供更高的吞吐，通常還可以提供更大的存儲(chǔ)空間。例如，各個(gè)云廠商的云盤存儲(chǔ)都可以提供 12 TB 或 32 TB 的存儲(chǔ)空間，基本上可以滿足各類業(yè)務(wù)需要。

當(dāng)然，使用云盤也有一些缺點(diǎn)，例如，相比本地盤，云盤的訪問(wèn)延遲更大，需要通過(guò)網(wǎng)絡(luò)訪問(wèn)，而對(duì)于數(shù)據(jù)庫(kù)這類 IO 極其敏感的應(yīng)用，本地磁盤的 IO 性能的穩(wěn)定性通常會(huì)更強(qiáng)一些。

2.6 關(guān)于通用型與獨(dú)享型的性能

獨(dú)享型規(guī)格的資源完全由用戶獨(dú)立使用，價(jià)格通常更貴。而通用型則因?yàn)椴糠仲Y源的共享，會(huì)導(dǎo)致性能在某些不可預(yù)期的情況下發(fā)生一些不可預(yù)期的波動(dòng)。而獨(dú)享型規(guī)格也更貴，更多的企業(yè)級(jí)場(chǎng)景，也會(huì)推薦使用獨(dú)享型，會(huì)有很多人會(huì)認(rèn)為獨(dú)享型的性能也更高。而實(shí)際上，如果做過(guò)實(shí)際測(cè)試就會(huì)發(fā)現(xiàn)，一般來(lái)說(shuō)，相同的規(guī)格，通用型的性能與吞吐通常都會(huì)更高。

所以，實(shí)際情況是，通用型的價(jià)格更加便宜，性能也會(huì)更好。缺點(diǎn)在于，可能會(huì)出現(xiàn)一些不可預(yù)期的性能波動(dòng)，而因?yàn)榇蠖鄶?shù)數(shù)據(jù)庫(kù)應(yīng)用都是 IO 密集型的，所以，實(shí)際場(chǎng)景中，這種不可預(yù)期的波動(dòng)并不是非常多。

所以，這兩個(gè)版本的選擇，需要用戶根據(jù)自己的實(shí)際情況去選擇。如果，可以接受偶爾的性能波動(dòng)，則一定是建議選擇通用型的；如果應(yīng)用對(duì)數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間極其敏感，則應(yīng)該選擇獨(dú)享型。另外，當(dāng)前，通用型最大規(guī)格僅支持 12核 CPU，所以對(duì)于壓力非常大系統(tǒng)，則只能選擇獨(dú)享型。

2.7 關(guān)于超配比

對(duì)于在線數(shù)據(jù)庫(kù)應(yīng)用來(lái)說(shuō)，通常是 IO 或者吞吐密集型的。CPU 資源在很多時(shí)候，會(huì)有一定的冗余。對(duì)于云廠商來(lái)說(shuō)，則可以通過(guò)超配 CPU 的售賣率來(lái)降低成本，同時(shí)也降低數(shù)據(jù)庫(kù)資源的價(jià)格，這就是通用型背后重要的邏輯。

而一般來(lái)說(shuō)，可以超配的通常只有 CPU 資源。磁盤資源雖然可以超配，但是實(shí)際使用中，是不能重合的，當(dāng)用戶的磁盤占用增到購(gòu)買值的時(shí)候，資源則不可以共享，這與 CPU 的超配并不相同。內(nèi)存資源則更加是獨(dú)享的，Buffer Pool 的通常是滿的，無(wú)論這些內(nèi)存頁(yè)是否被實(shí)際使用，數(shù)據(jù)庫(kù)總是會(huì)盡力在內(nèi)存中存儲(chǔ)盡可能多的數(shù)據(jù)。

MyBase 提供的一個(gè)重要配置項(xiàng)，就是可以由用戶自定義底層資源的超配比，該比率取值從100%~300%。也就是說(shuō)，一個(gè) 32核 CPU 的資源，最多可以分配給12個(gè)8核 CPU 的實(shí)例使用，看起來(lái)是96=12*8個(gè) CPU 被使用，即實(shí)現(xiàn)了 300% 的超配比。

超配比，有時(shí)候也會(huì)被稱為超賣率。

2.8 ARM 架構(gòu)實(shí)例支持

阿里云數(shù)據(jù)庫(kù)在去年11月宣布推出基于 ARM 架構(gòu)的 RDS 實(shí)例，可以向用戶提供更高性價(jià)比。根據(jù) ARM 芯片的定位，一般性價(jià)比更高，但是性能上限相比于 x86 的芯片要差一些。所以，如果數(shù)據(jù)庫(kù)實(shí)例壓力不是很大，而又考慮成本降低，則可以考慮嘗試 ARM 架構(gòu)的 RDS。

另外，zhoujy 在去年11月份對(duì)該實(shí)例進(jìn)行測(cè)試，相關(guān)的數(shù)據(jù)庫(kù)可以參考：MySQL該用哪種CPU架構(gòu)服務(wù)器。

當(dāng)前，基于 ARM 的 RDS 實(shí)例上線時(shí)間還不是很長(zhǎng)，如果是生產(chǎn)環(huán)境的話，建議做較為全面的測(cè)試后再上線。

2.9 RDS MySQL 集群版

在2022年底，阿里云 RDS MySQL 發(fā)布了集群版。該產(chǎn)品形態(tài)類似于 AWS 提供的“Multi-AZ Cluster”，場(chǎng)景也比較類似。對(duì)比最常用的雙節(jié)點(diǎn)高可用版本，該”集群版”將其備庫(kù)的連接地址提供了出來(lái)，直接可以用于用戶業(yè)務(wù)，幫助用戶降低使用成本。另外，也可以考慮將主庫(kù)的部分流量直接遷移到備節(jié)點(diǎn)，降低主庫(kù)壓力，提升主庫(kù)的可用性。

如果，在業(yè)務(wù)場(chǎng)景中，使用了1~2個(gè)只讀實(shí)例的，則可以考慮直接使用該集群版本來(lái)代替原有的只讀實(shí)例。成本可以得到非常大的降低。

2.10 Serverless 實(shí)例

RDS Serverless 是一種優(yōu)于按量付費(fèi)、包年包月的資源使用的模式。它提供了自動(dòng)化的彈性擴(kuò)縮容，用戶無(wú)需提前選定規(guī)格，后端會(huì)根據(jù)系統(tǒng)壓力進(jìn)行自動(dòng)升降配，并根據(jù)實(shí)際使用計(jì)費(fèi)，當(dāng)然，用戶可以設(shè)置 Serverless 實(shí)例的最大和最小規(guī)格，限制資源最大使用量和最低的服務(wù)能力。

對(duì)于峰谷明顯的業(yè)務(wù)系統(tǒng)，該模式一方面可以在需要時(shí)提供很高的資源規(guī)格應(yīng)對(duì)壓力，另一方面可以在低峰時(shí)降低資源使用量，最終降低成本。

也注意到，最近阿里云數(shù)據(jù)庫(kù)也介紹了客戶“微財(cái)”使用 Serverless 實(shí)例構(gòu)建云上災(zāi)備的案例。使用 Serverless 構(gòu)建云端低成本的災(zāi)備，確實(shí)是一個(gè)非常好的場(chǎng)景，一方面滿足了客戶底層本的訴求，另一方面客戶本地的實(shí)例如果真的出問(wèn)題，依舊可以非?？焖俚慕庸?。

關(guān)于更多 Serverless 測(cè)試可以參考：實(shí)測(cè)阿里云 RDS Serverless。

2.11 其他

本架構(gòu)圖主要反映阿里云數(shù)據(jù)庫(kù) RDS 的主要架構(gòu)；

ARM CPU 僅部分?jǐn)?shù)據(jù)庫(kù)部分規(guī)格支持，當(dāng)前僅 MySQL、PostgreSQL 支持；

“集群版”僅 MySQL 和 SQL Server 支持；

不同數(shù)據(jù)庫(kù)的不同的版本，支持的架構(gòu)和規(guī)格都有不同，這里并沒(méi)有體現(xiàn)出來(lái)；

不同的區(qū)域支持的數(shù)據(jù)庫(kù)、版本均可能不同；

該圖的完成得到了阿里云 RDS 團(tuán)隊(duì)的幫助，在此一并表示感謝；

v1 版本發(fā)布于2022年5月；v2 版本發(fā)布于2023年2月。

三、阿里云 RDS vs AWS RDS 選型差異

AWS 和阿里的數(shù)據(jù)庫(kù)產(chǎn)品各自都發(fā)展了很長(zhǎng)時(shí)間，所處的市場(chǎng)環(huán)境、客戶場(chǎng)景都有很大的不同，所以，其產(chǎn)品形態(tài)也有很多不同的地方，即便是看似相同的名稱其含義也可能不同。這里整理，阿里云和 AWS RDS 產(chǎn)品的一些差異，以便幫助大家更好的選擇產(chǎn)品：

3.1 基礎(chǔ)版 vs 單可用區(qū)版本

無(wú)論是在阿里云還是 AWS，這兩個(gè)版本都是代表了單節(jié)點(diǎn)的架構(gòu)。但是：

阿里云的“基礎(chǔ)版”，強(qiáng)調(diào)“基礎(chǔ)”，所以均為小規(guī)格，最大只有 12v CPU，也沒(méi)有高可用節(jié)點(diǎn)，所以也就只能在一些小場(chǎng)景，如測(cè)試環(huán)境，中使用。

AWS 則強(qiáng)調(diào)是“單可用區(qū)”版本，并不一定是小規(guī)格，其最大規(guī)格也可以到 128v CPU，所以其使用場(chǎng)景要更廣泛。例如，部分分析業(yè)務(wù)節(jié)點(diǎn)使用，該類型可能需要非常強(qiáng)的計(jì)算能力，但是可以接受一定程度的可用性問(wèn)題。

3.2 阿里云高可用版 vs AWS多可用區(qū)版

這兩個(gè)版本都是各自廠商的主流版本，是符合大部分 OLTP 業(yè)務(wù)場(chǎng)景的。但兩個(gè)廠商的實(shí)現(xiàn)各有一些不同，阿里云使用的是數(shù)據(jù)庫(kù)層的邏輯復(fù)制，AWS 使用了 EBS 層的同步物理復(fù)制。阿里云 RDS MySQL 在數(shù)據(jù)保護(hù)上，則提供了“高性能”、“異步模式”、“默認(rèn)”等參數(shù)模板，可以讓用戶在數(shù)據(jù)保護(hù)和性能之間進(jìn)行一定平衡和選擇，而 AWS RDS 則使用了 EBS 的同步物理復(fù)制，最大限度的保護(hù)事務(wù)安全。

3.3 阿里云 ARM vs AWS Graviton

阿里云 RDS 的 ARM 規(guī)格上線時(shí)間比較短，如果要考慮在生產(chǎn)環(huán)境使用，還是建議做較為充分的業(yè)務(wù)測(cè)試。相比，AWS Graviton 實(shí)例已經(jīng)上線有3年時(shí)間，也有很多的使用案例，相對(duì)要更加的穩(wěn)定。另外，AWS Graviton 實(shí)例在性價(jià)比上確實(shí)更加明顯，這一點(diǎn)，無(wú)論是第三方的測(cè)試還是官方公布的一些數(shù)據(jù)，都得到了證實(shí)。所以，如果部分業(yè)務(wù)，考慮降低成本，則可以嘗試使用 AWS Graviton 實(shí)例。

3.4 ESSD vs gp2/gp3/io1

ESSD 的性能上限是更高的，目前 ESSD PL-X 類型已經(jīng)聲稱提供了300萬(wàn)的 IOPS 能力。AWS RDS 所使用的 io1 最大 IOPS 則是25.6萬(wàn)。一直以來(lái)，AWS RDS 被詬病比較多的是其按照 IOPS 計(jì)費(fèi)的復(fù)雜邏輯，雖然，看似產(chǎn)品細(xì)節(jié)非常細(xì)致，但是實(shí)際讓用戶選擇和使用的時(shí)候很困惑，另一面，阿里云和其他云廠商都以存儲(chǔ)空間計(jì)費(fèi)，更加簡(jiǎn)單，并提供與存儲(chǔ)空間大小為一定比率的 IOPS 能力。

AWS 存儲(chǔ)的一個(gè)優(yōu)點(diǎn)是，其提供了非常明確的 IOPS SLA，io1 規(guī)格，其 SLA 是99.9%的 IO 請(qǐng)求響應(yīng)時(shí)間是毫秒級(jí)，這反應(yīng)了 AWS 可以向用戶提供非常穩(wěn)定的 IOPS，而不是僅僅簡(jiǎn)單的最求 IOPS 上限。

3.5 資源共享 vs 突發(fā)型

AWS 在小規(guī)格的版本提供了突發(fā)性能型實(shí)例，可以提供一定的 CPU “超用”（購(gòu)買了 2v CPU，實(shí)際使用更多 v CPU）能力，同時(shí)，其“超用”和限制的規(guī)則都非常明確。

阿里云則為了更好的性價(jià)比，則向用戶提供了“共享型”、“通用型”、“獨(dú)享型”，讓用戶在性能穩(wěn)定性犧牲非常非常小的情況下，獲得更高性價(jià)比的實(shí)例規(guī)格。另外，阿里云提供的 MyBase 規(guī)格，更可以自己定義“超賣”比率，讓用戶根據(jù)自己的業(yè)務(wù)類型和特點(diǎn)進(jìn)行自定義的配置。阿里云的“獨(dú)享型”資源則全部由用戶獨(dú)立使用，也可以保障非常好的性能穩(wěn)定性。

3.6 規(guī)格代碼

AWS 的規(guī)格代碼非常簡(jiǎn)潔、準(zhǔn)確，含義清晰，并且有非常好的連續(xù)性。從規(guī)格代碼中很容易了解到該規(guī)格的特點(diǎn)、大小等特性。

四、最后

阿里云和 AWS 兩家的云廠商的數(shù)據(jù)庫(kù)服務(wù)都經(jīng)過(guò)了十來(lái)年的發(fā)展，他們?cè)诟髯缘氖袌?chǎng)和場(chǎng)景下，都非常好的滿足了他們客戶的訴求，本文檔旨在幫助大家能夠從整體框架加上了解兩家廠商主要數(shù)據(jù)庫(kù)產(chǎn)品 RDS 的架構(gòu)。所以在介紹中省略了非常多的細(xì)節(jié)內(nèi)容，也犧牲了一定的精確性，這些內(nèi)容可以參考各種廠商的文檔，這里不做贅述。

周振興（蘇普），NineData.cloud 聯(lián)合創(chuàng)始人，Oracle ACE（MySQL方向），數(shù)據(jù)庫(kù)領(lǐng)域暢銷書《高性能MySQL》第三、四版的譯者，曾任阿里云數(shù)據(jù)庫(kù)資深專家。

審核編輯黃宇