NineData 聯合創始人周振興（蘇普）受邀參加2023年 ACMUG 第一站西安站，發表了《云數據庫架構與選型》主題演講。

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

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

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

一、AWS：選擇合適的 RDS 架構與規格

1.1 架構與規格大圖

該架構圖包含了高可用架構、CPU 架構選擇、存儲類型選擇等內容。該架構圖不包括性能、精確的對應關系（如 SQL Server 支持的存儲空間大小與 MySQL 有什么差別）等內容，暫時不包括 Aurora 架構（后續考慮補充）、Custom、Outpost 類型等。

1.2 高可用架構

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

1.2.1 單/多可用區

該選項清晰的描述了實例的在可用區級別的容災能力：

單可用區版本的數據庫僅一個實例，沒有高可用節點，如果節點失敗，則會重啟主機或者使用新的節點，整個過程會比較長。

多可用區版本，則默認會使用兩個節點，且一定分布在兩個不同的可用區，實例可以實現跨可用區的容災。當一個可用區出現故障的時候，實例會發生切換，容災到另一個可用區。AWS 的多可用區版本，主備之間使用的是存儲層（EBS）的物理復制，所以因此其性能也會受到一定的限制。

1.2.2 多可用區集群版

這是 Amazon RDS 在去年發布新的架構形態，詳細參考：AWS RDS 發布三節點形態，哪些業務場景應該選擇？。該形態主要解決原來的“多可用區版本”備節點完全不可用（相對成本較高）的問題。

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

該版本，似乎是當前 Amaozn RDS 主推的版本（從 RDS 創建流程中的默認選項和選項順序來看）。

當前，多可用區集群版是標準模板中的第一個、也是默認選項。

關于該版本的架構、優缺點等相關信息可以參考該文章獲得更多詳細內容：AWS RDS 發布三節點形態，哪些業務場景應該選擇？

1.3 CPU 架構

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

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

當前的建議是：可以考慮在部分業務中嘗試使用 Graviton 降低成本，根據企業內部的負載情況，再逐步考慮擴大范圍使用。

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

1.4 存儲層

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

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

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

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

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

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

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

在實際的選擇中，開發測試環境則可以使用 gp2 類型、一般業務使用 gp3 類型，對于核心業務則可以使用 io1 類型。

1.5 規格代碼

關于規格代碼，國內的云廠商一般不是太強調，也不是太關注。但是 AWS 因為其規格代碼非常規范，也非常簡潔，所傳達的含義也比較準確，所以很多時候，在提及規格時，大家會使用其規格代碼，而不是使用 vcpu 數量和內存大小。

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

規格代碼中的“db”代表了這是一個用于數據庫的實例（ec2）；

{t|m|r|x}分別代表了突發型實例 t（小規格）、標準實例 m（內存 cpu 比為4）、內存優化型 r（內存 cpu 比為8）、內存優化型 x（內存 cpu 比為16）；

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

數字之后的可能出現的字母包括：g、d、n、i等。g代表這是一個 Graviton 類型的實例、d 代表該實例本地有額外的、增強的存儲資源、n則代表了額外的網絡能力、i 代表這是一個 Intel X86 架構的實例。

1.6 其他

1.6.1 關于“可用區”

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

1.6.2 補充說明

本文內容主要聚焦于使用最多的各個云廠商的 RDS 數據庫的架構與選型，并不包括完整的產品系列；

該架構圖旨在幫助大家從整體框架上了解云數據庫整體概括，并不是精確的架構圖，并不求精確、面面俱到，例如 RDS MySQL、RDS SQL Server在很多細節上是不同的，這里并沒有體現，這些詳情可以參考各個云廠商的相關文檔；

這里不包括價格、性能相關的內容。

二、阿里云：選擇合適的 RDS 架構與規格

2.1 架構與規格大圖

一張圖讀懂阿里云數據庫 RDS 架構與選型

在 v1 版本發布的時候，詳細的介紹了阿里云數據庫 RDS 主要架構類型、資源復用與規格、數據庫專屬集群、本地盤與云盤版、通用型與獨享型、超配比等內容，這里不再贅述，如果感興趣可以參考：一張圖讀懂阿里云數據庫架構與選型。

2.2 主要的架構類型

數據庫通常是企業業務架構中的核心組件，數據庫的可用性與業務可用性直接相關。所以，高可用是云數據庫架構選型第一個需要關注的內容。

從高可用角度，阿里云數據庫提供了基礎版（即單節點）、雙節點高可用版、三節點企業版。不同的版本，則是在成本、可用性、數據可靠性之間的平衡：

單節點通過簡單的架構，以最低的成本提供了基本可用的云數據庫服務；

雙節點高可用版則是適合絕大多數業務場景的模式，兩個節點分布于一個地區的兩個可用區，故障時，切換速度較快，數據雙副本，可靠性也比較高；

三節點企業版，則通過 X-Paxos 實現底層數據一致，并以三副本（兩份數據+一份日志）保障數據可靠性。

2.2.1 基礎版（即單節點版本）

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

2.2.2 高可用版

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

具體的，對阿里云 RDS MySQL，阿里云的兩節點高可用，根據所選擇的參數模板分為如下三類：

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

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

默認：sync_binlog=1, innodb_flush_log_at_trx_commit=1, semi-sync。

其中，“高性能”版本和“異步”版本，都是異步復制，在發生主節點故障時，因為復制為異步的，可能會有少部分的事務日志沒有傳到備節點，則可能會丟失少部分事務。也就是說，這兩個版本為了實現更好的性能，在數據庫的 RPO 上做了小的讓步。“默認”版本，使用了半同步復制，通常，數據可靠性會更高。但因為半同步可能會有退化的場景，所以，該模式下數據復制還是在極端的情況下，還會有數據丟失的可能性。

那么，既然“異步”模式和“高性能”都有數據丟失的風險，他們的區別是什么什么呢？簡單的概括，“異步”產生微小數據丟失的可能性更小。因為，主備節點通過設置sync_binlog=1,
innodb_flush_log_at_trx_commit=1，可以最大可能性的保障，主節點的數據可靠性。

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

兩節點高可用版本在某些特殊場景下，數據還是存在一些不可用風險，例如，當其中一個節點發生故障，而本地數據量又非常大時，需要重新在一臺新的機器上搭建備節點時，因為數據量較大，重建時間通常會比較長，而這時候，主節點則會一直單節點運行，如果不幸主節點再出現故障，則會出現不可用或者數據丟失。如果，對數據的安全性有更高的要求，則可以考慮選擇“三節點企業版”。

2.2.3 三節點企業版

當前僅 RDS MySQL 有該版本。三節點企業版使用了基于 X-Paxos[^4] 的一致性協議實現了數據的同步復制，適用于數據安全可靠性要求非常高的場景，例如金融交易數據等。三節點中，有一個節點僅存儲日志，以此實現接近于兩個節點的成本與價格，實現更高的數據安全與可靠性。

三節點企業版在創建的時候，可以選擇分布在1~3個可用區。如果需要跨可用區的容災，則可以讓三個副本分布于三個可用區，如果需要更高的性能，則可以讓三個副本都在同一個可用區。

2.2.4 關于MySQL的參數sync_binlog, innodb_flush_log_at_trx_commit

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

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

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

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

其中 1 最嚴格，代表每個事務完成后都會刷寫到磁盤中。

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

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

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

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

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

2.3 資源復用與規格

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

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

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

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

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

2.4 數據庫專屬集群 MyBase

專屬集群 MyBase 是阿里云推出的一種特殊的形態。可以理解為，是一種全托管 RDS 與自建數據庫的中間形態。在全托管的 RDS 基礎上，提供了兩個重大的能力：

允許用戶登錄數據庫所在的主機；

允許用戶配置數據庫實例 CPU 的“超配比”。

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

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

2.5 關于本地盤與云盤版

阿里云的主要版本都會支持本地 SSD 和高性能云盤。他們的差異在于計算節點與磁盤存儲是否在同一臺物理機器上，對于使用高性能云盤的規格，通常是通過掛載一個同地區的網絡塊設備作為存儲。

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

統一使用云盤版，讓云廠商的供應鏈管理變得簡單。如果使用本地盤版本，意味著數據庫機型定制性會增強，供應鏈的困難會增加產品的成本，最終影響價格。另外，簡單的供應鏈也會讓產品的部署更加標準化，更加敏捷地實現多環境多區域的部署。

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

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

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

當然，使用云盤也有一些缺點，例如，相比本地盤，云盤的訪問延遲更大，需要通過網絡訪問，而對于數據庫這類 IO 極其敏感的應用，本地磁盤的 IO 性能的穩定性通常會更強一些。

2.6 關于通用型與獨享型的性能

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

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

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

2.7 關于超配比

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

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

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

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

2.8 ARM 架構實例支持

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

另外，zhoujy 在去年11月份對該實例進行測試，相關的數據庫可以參考：MySQL該用哪種CPU架構服務器。

當前，基于 ARM 的 RDS 實例上線時間還不是很長，如果是生產環境的話，建議做較為全面的測試后再上線。

2.9 RDS MySQL 集群版

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

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

2.10 Serverless 實例

RDS Serverless 是一種優于按量付費、包年包月的資源使用的模式。它提供了自動化的彈性擴縮容，用戶無需提前選定規格，后端會根據系統壓力進行自動升降配，并根據實際使用計費，當然，用戶可以設置 Serverless 實例的最大和最小規格，限制資源最大使用量和最低的服務能力。

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

也注意到，最近阿里云數據庫也介紹了客戶“微財”使用 Serverless 實例構建云上災備的案例。使用 Serverless 構建云端低成本的災備，確實是一個非常好的場景，一方面滿足了客戶底層本的訴求，另一方面客戶本地的實例如果真的出問題，依舊可以非常快速的接管。

關于更多 Serverless 測試可以參考：實測阿里云 RDS Serverless。

2.11 其他

本架構圖主要反映阿里云數據庫 RDS 的主要架構；

ARM CPU 僅部分數據庫部分規格支持，當前僅 MySQL、PostgreSQL 支持；

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

不同數據庫的不同的版本，支持的架構和規格都有不同，這里并沒有體現出來；

不同的區域支持的數據庫、版本均可能不同；

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

v1 版本發布于2022年5月；v2 版本發布于2023年2月。

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

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

3.1 基礎版 vs 單可用區版本

無論是在阿里云還是 AWS，這兩個版本都是代表了單節點的架構。但是：

阿里云的“基礎版”，強調“基礎”，所以均為小規格，最大只有 12v CPU，也沒有高可用節點，所以也就只能在一些小場景，如測試環境，中使用。

AWS 則強調是“單可用區”版本，并不一定是小規格，其最大規格也可以到 128v CPU，所以其使用場景要更廣泛。例如，部分分析業務節點使用，該類型可能需要非常強的計算能力，但是可以接受一定程度的可用性問題。

3.2 阿里云高可用版 vs AWS多可用區版

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

3.3 阿里云 ARM vs AWS Graviton

阿里云 RDS 的 ARM 規格上線時間比較短，如果要考慮在生產環境使用，還是建議做較為充分的業務測試。相比，AWS Graviton 實例已經上線有3年時間，也有很多的使用案例，相對要更加的穩定。另外，AWS Graviton 實例在性價比上確實更加明顯，這一點，無論是第三方的測試還是官方公布的一些數據，都得到了證實。所以，如果部分業務，考慮降低成本，則可以嘗試使用 AWS Graviton 實例。

3.4 ESSD vs gp2/gp3/io1

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

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

3.5 資源共享 vs 突發型

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

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

3.6 規格代碼

AWS 的規格代碼非常簡潔、準確，含義清晰，并且有非常好的連續性。從規格代碼中很容易了解到該規格的特點、大小等特性。

四、最后

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

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

審核編輯黃宇