從高可用區架構上，分為單節點（基礎版）、雙節點（高可用版）以及三節點企業版、集群版（僅SQL Server AlwaysOn）。從資源共享與隔離上，則分為通用型、獨享型、共享型和獨佔物理機（可以理解為是特殊的獨享型）。從磁碟使用上的不同，則分為雲盤版和本地盤版。

當前，RDS最大規格為104核CPU，768GB記憶體。其中通用型，最大為12核CPU；共享型最大為32核CPU。

02 主要的架構類型

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

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

• 單節點通過簡單的架構，以最低的成本提供了基本可用的雲資料庫服務

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

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

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

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

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.3 三節點企業版

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

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

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有著非常大的性能差異。通常，這些差異並不是廠商之前的技術能力導致的，更多的是由於他們在對於安全性和性能的平衡時，選擇的不同的平衡點。

03資源復用與規格

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

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

• 「獨享型」則使用完全獨享的CPU的資源和記憶體資源，不會共享其他人的資源，自己的資源也不會被其他人共享，所以，有更穩定的性能。

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

除了，上述主要規格類型之外，阿里雲還提供了「獨佔物理機」規格，選擇該規格的用戶可以完全的獨佔一台物理機的資源：

 04資料庫專屬集群MyBase

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

• 允許用戶登錄資料庫所在的主機

• 允許用戶配置資料庫實例CPU的「超配比」

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

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

05關於本地盤與雲盤版

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

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

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

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

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

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

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

06關於通用型與獨享型的性能

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

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

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

07關於超配比

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

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

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

參考文檔

• 阿里雲RDS for MySQL 發布三節點企業版 @阿里雲開發者社區

• RDS 使用參數模板 @阿里雲資料庫文檔

• sync_binlog @MySQL Documentation

• innodb_flush_log_at_trx_commit @MySQL Documentation

• 實例規格族 @ 阿里雲資料庫文檔

• 高清無水印大圖下載：   

  //cloud-database-tech.github.io/images/aliyun-instance-type-code-without-qr-code.png

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