如何選擇合適的云數(shù)據(jù)庫架構(gòu)與規(guī)格

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

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

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

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

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

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

該架構(gòu)圖包含了高可用架構(gòu)、CPU 架構(gòu)選擇、存儲類型選擇等內(nèi)容。該架構(gòu)圖不包括性能、精確的對應(yīng)關(guān)系（如 SQL Server 支持的存儲空間大小與 MySQL 有什么差別）等內(nèi)容，暫時不包括 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）這兩種常見類型，RDS MySQL/PostgreSQL 還提供了多可用區(qū)集群版（Multi-AZ DB Cluster）。

1.2.1 單/多可用區(qū)

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

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

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

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

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

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

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

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

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

1.3 CPU 架構(gòu)

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

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

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

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

1.4 存儲層

接著來看看 AWS RDS 提供了哪些存儲類型。

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

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

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

gp2、gp3 存儲所提供的 SLA 都是99%的請求在毫秒級別。

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

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

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

1.5 規(guī)格代碼

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

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

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

{t|m|r|x}分別代表了突發(fā)型實例 t（小規(guī)格）、標(biāo)準(zhǔn)實例 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代表這是一個 Graviton 類型的實例、d 代表該實例本地有額外的、增強(qiáng)的存儲資源、n則代表了額外的網(wǎng)絡(luò)能力、i 代表這是一個 Intel X86 架構(gòu)的實例。

1.6 其他

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

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

1.6.2 補(bǔ)充說明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.2 高可用版

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

具體的，對阿里云 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)故障時，因為復(fù)制為異步的，可能會有少部分的事務(wù)日志沒有傳到備節(jié)點(diǎn)，則可能會丟失少部分事務(wù)。也就是說，這兩個版本為了實現(xiàn)更好的性能，在數(shù)據(jù)庫的 RPO 上做了小的讓步?！澳J(rèn)”版本，使用了半同步復(fù)制，通常，數(shù)據(jù)可靠性會更高。但因為半同步可能會有退化的場景，所以，該模式下數(shù)據(jù)復(fù)制還是在極端的情況下，還會有數(shù)據(jù)丟失的可能性。

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

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

兩節(jié)點(diǎn)高可用版本在某些特殊場景下，數(shù)據(jù)還是存在一些不可用風(fēng)險，例如，當(dāng)其中一個節(jié)點(diǎn)發(fā)生故障，而本地數(shù)據(jù)量又非常大時，需要重新在一臺新的機(jī)器上搭建備節(jié)點(diǎn)時，因為數(shù)據(jù)量較大，重建時間通常會比較長，而這時候，主節(jié)點(diǎn)則會一直單節(jié)點(diǎn)運(yùn)行，如果不幸主節(jié)點(diǎn)再出現(xiàn)故障，則會出現(xiàn)不可用或者數(shù)據(jù)丟失。如果，對數(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é)議實現(xiàn)了數(shù)據(jù)的同步復(fù)制，適用于數(shù)據(jù)安全可靠性要求非常高的場景，例如金融交易數(shù)據(jù)等。三節(jié)點(diǎn)中，有一個節(jié)點(diǎn)僅存儲日志，以此實現(xiàn)接近于兩個節(jié)點(diǎn)的成本與價格，實現(xiàn)更高的數(shù)據(jù)安全與可靠性。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

專屬集群 MyBase 是阿里云推出的一種特殊的形態(tài)?？梢岳斫鉃椋且环N全托管 RDS 與自建數(shù)據(jù)庫的中間形態(tài)。在全托管的 RDS 基礎(chǔ)上，提供了兩個重大的能力：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.7 關(guān)于超配比

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

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

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

超配比，有時候也會被稱為超賣率。

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

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

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

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

2.9 RDS MySQL 集群版

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

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

2.10 Serverless 實例

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

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

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

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

2.11 其他

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這兩個版本都是各自廠商的主流版本，是符合大部分 OLTP 業(yè)務(wù)場景的。但兩個廠商的實現(xiàn)各有一些不同，阿里云使用的是數(shù)據(jù)庫層的邏輯復(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ī)格上線時間比較短，如果要考慮在生產(chǎn)環(huán)境使用，還是建議做較為充分的業(yè)務(wù)測試。相比，AWS Graviton 實例已經(jīng)上線有3年時間，也有很多的使用案例，相對要更加的穩(wěn)定。另外，AWS Graviton 實例在性價比上確實更加明顯，這一點(diǎn)，無論是第三方的測試還是官方公布的一些數(shù)據(jù)，都得到了證實。所以，如果部分業(yè)務(wù)，考慮降低成本，則可以嘗試使用 AWS Graviton 實例。

3.4 ESSD vs gp2/gp3/io1

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

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

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

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

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

3.6 規(guī)格代碼

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

四、最后

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

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

審核編輯黃宇