天天看點

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

背景

阿裡雲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

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

~~~~~~~~~~~~~~~

萬物之中,希望至美

~~~~~~~~~~~~~~~

繼續閱讀