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

jyzhou 發表於 2022-05-19
資料庫

背景

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

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

 

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

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

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

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

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

 

0主要的架構型別

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

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

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

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

  • 三節點企業版,則通過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

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