一張圖讀懂阿里雲資料庫架構與選型

背景

阿里雲RDS已經發展超過十年，在演進的過程中，其架構和規格已經變得比較複雜，本文嘗試通過一張架構圖，較為完整的概況RDS所支援的主要的架構型別、規格，幫助開發者從高可用、成本、可靠性等角度選擇適合自己業務的RDS型別與規格。

具體的資訊可以看：一張圖讀懂阿里雲資料庫架構與選型，或則關注公眾號  ，能夠第一時間瞭解行業動態。

 

01 阿里雲RDS的架構與規格大圖

下圖從高可用型別、資料可靠性、資源複用率、規格大小、規格程式碼等角度，較為完整的概況了當前RDS主要的架構與規格：

  

從高可用區架構上，分為單節點（基礎版）、雙節點（高可用版）以及三節點企業版、叢集版（僅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

• 例項規格族 @ 阿里雲資料庫文件

• 高清無水印大圖下載：   

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

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