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

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

![](http://img.blog.itpub.net/blog/2023/04/03/ca371636e2cf6adb.jpeg?x-oss-process=style/bb)

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

AWS 在 2009 年釋出第一款雲資料庫產品 RDS MySQL，阿里雲於2011年 也釋出了自己的 RDS MySQL，到現在，雲資料庫技術已經經過了 14 年的發展。雲資料庫的架構已經變得非常複雜，上週則藉著 ACMUG（中國 MySQL 使用者組）的分享則總結了 AWS 和阿里雲 RDS 的主要架構特點，並透過一張架構圖彙總，幫助開發者根據需要在合適的場景選擇合適的架構與規格。

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

# 1.1 架構與規格大圖

![](http://img.blog.itpub.net/blog/2023/04/03/234aaa9fc198d371.png?x-oss-process=style/bb)

該架構圖包含了高可用架構、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 建立流程中的預設選項和選項順序來看）。

![](http://img.blog.itpub.net/blog/2023/04/03/bf139aa8241ac1ad.png?x-oss-process=style/bb)

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

關於該版本的架構、優缺點等相關資訊可以參考該文章獲得更多詳細內容：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 架構與規格大圖

![](http://img.blog.itpub.net/blog/2023/04/03/ac06853479ebd374.png?x-oss-process=style/bb)

一張圖讀懂阿里雲資料庫 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 引擎層面保障了事務的永續性。在事務提交的時候，資料庫會先將資料“寫入檔案系統”，通常檔案系統會先將資料寫入檔案快取中，該快取是在記憶體中，這樣就意味著，如果發生作業系統級別的當機，那麼寫入的日誌就會丟失。為了避免這種資料丟失，資料庫接著會透過系統呼叫，“刷寫資料到磁碟”中。此時，即可以認為資料已經持久化到磁碟中。

![](http://img.blog.itpub.net/blog/2023/04/03/b4d7b2d2e757a6aa.png?x-oss-process=style/bb)

這時，再回頭看看阿里雲 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 支援。

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

![](http://img.blog.itpub.net/blog/2023/04/03/7c3b84d10f245995.png?x-oss-process=style/bb)

# 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 提供的一個重要配置項，就是可以由使用者自定義底層資源的超配比，該比率取值從10 0%~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 產品的一些差異，以便幫助大家更好的選擇產品：

![](http://img.blog.itpub.net/blog/2023/04/03/e1dcd8abd8f1939f.png?x-oss-process=style/bb)

# 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》第三、四版的譯者，曾任阿里雲資料庫資 深專家。

如何選擇合適的雲資料庫架構與規格

相關文章