簡介：從綠色低碳到硬核科技，看RDS如何用綠色科技助力2021“雙11”？

雙十一回顧

從平臺到商家，再從物流到客戶手中，云數據庫RDS支撐著雙11集團電商的在線業務。RDS首次對集團核心業務進行國產化技術演進試點，具備x86等同性能并兼顧穩定性。針對大促態瞬間大量流量請求場景，內核通過分庫分表級別的多點寫、熱點更新優化、Statement Queue及慢SQL限流等深度內核優化，同時搭配資源獨共享混部調度能力，使張北單元大促成本下降30%+，綠色低碳穩定的輕松應對逐年遞增的流量洪峰。

RDS集團業務支撐

2019年，集團上云戰役開始；到目前為止，集團交易相關RDS已經實現100%云化。當然，上云的背后離不開RDS的針對大B客戶上云的后臺技術支撐。在資源充足的情況下，通過系統優化一鍵上云成功率已達到99%。同時，新開深圳、德國、美東等物理Region支持全球集團業務。對于阿里技術團隊來說，每年最閃亮的時候就是雙11；很多人最感興趣的是阿里如何做到順滑的應對這種類似DDOS的洪峰流量的。下面我為大家一一揭秘業務玩法。

大促態集團異地多活

每年雙十一的前幾周，對于RDS團隊來說，最迫切的事情是需要進行大促新單元建站。受資源交付影響，今年時間壓縮得比較緊張，相當于三天就需要搞定整個核心集群的建站工作，為業務分流壓測做準備。相比去年的人海戰術，今年通過RDS自研的內部運維系統督威，快速完成了建站、全網擴容、調參以及巡檢一致性校驗等相關的工作，為業務分流壓測提供足夠的時間來保證穩定。

異地多活可以根據用戶的流量Region來識別在任意單元進行交易，在大促態時可以做到各單元自閉，同時提供寫能力。這樣能充分的分擔峰值流量，提供更穩定的服務。

核心交易集群的實例日常態有兩套獨立的三節點集群，他們之間通過DTS進行雙向復制。在大促態需要再增加一套三節點集群，這樣基于單元能分擔更多的讀寫流量，做到單元自閉，各單元可同時讀寫。大家也許有疑問，同時寫會不會產生主鍵沖突，怎么保證數據不會寫錯。這里集團RDS用到了DTS的Store和Writer，Writer主要將Store上的日志應用到對應單元去，又通過Store，由Writer反寫回去，兩套RDS之間數據表用不同的步長，做到防止主鍵沖突。傳統的防循環復制都是通過事務表來實現，而事務表性能表現不佳。通過Thread ID既能實現防循環復制，又能提升性能。

全球只讀和異地容災

為滿足用戶按地域讀流量快讀訪問的業務場景，RDS提供全球只讀實例，異地只讀實例作為一個Learner加入到集群中，不參與主實例三節點的選舉，只同步數據和提供讀流量，復制采用基于Xcluster內核的原生復制來保證一致性。同時為滿足RPO=0的容災能力，單個只讀實例提供同AZ兩副本，針對RDS實例非健康狀態能快速切換來保證高可用，同時也提供機房容災能力。

內核Xcluster多點寫玩法

集團針對庫存業務，新增Xcluster內核提供多點寫能力，可以保證主備同時可寫，且沒有鎖沖突，能更進一步的利用容災的備庫資源，分擔讀寫性能。該形態相當于在內核層面實現分庫的Group級別的單向復制能力，類似MySQL中的Channel通道復制，該功能的好處是可以實行庫級別的多點寫入，主備同時提供讀寫能力，各自獨立數據通道互不影響，也不會有沖突問題，在滿足性能的同時更好的利用了備庫，也節約了資源。當然單個節點RDS服務不健康的時候，HA能夠快速的Failover過去，并實現故障轉移，能提供高可用服務。當然考慮到故障轉移流量都路由到一個節點場景，需要也能滿足業務需求，是性價比折中的形態。

底座ARM國產化試點

在2020年的雙十一中，我們的ARM國產化主要是MySQL+Ext4文件系統。今年我們在性能上做了更進一步的突破。

大家都知道普通的MySQL記錄寫入是過程是MySQL->OS->文件系統->寫磁盤。由于數據庫底層用的是分布式存儲，而底層存儲可以提供標準的POSIX給客戶端，因此我們在這方面做了很多性能優化的工作。

今年ARM MySQL國產化通過內核態改到用戶態這樣的改造，MySQL直接對接底層文件系統POSIX協議提升效率。

在完成上述改造以后，ARM節點部署在線上核心鏈路上并承擔復制流量。?

綠色低碳

在全球倡導綠色低碳的同時，作為技術人，我們用技術來響應全球的號召，使今年的雙十一張北單元大促成本下降30%+，在穩定性兼顧的同時做到綠色低碳。

RDS資源調度新創獨共享混部

每年雙十一核心集群會有獨立部署要求，當性能出現臨近點擴容時，就會造成資源浪費。今年新創的獨共享混部能力，將核心集群的實例和其他長尾實例混部，實現資源整合。張北混部單元今年全面采用這項技術，節省CPU核心數量4.5萬個；結合交易業務云盤化，張北單元整體大促成本下降 34.5%。在每個Node上，ECS主要分為幾個資源模塊。首先是主機預留，用于系統和對應管控組件，預留之外的都作為資源池給RDS使用，可分配獨享實例（相當于進行綁核獨享），也可以分配共享實例（相當于獨享和預留之外的核數用于共享使用）。這里CgroupController除了需要能夠為獨享實例綁定CPU核心以外，還需要維護共享實例的CPU資源池。

CgroupController會記錄當前節點上獨享CPU和共享CPU的核心分布，當節點上的獨享實例發生變化時，動態調整Node上共享Pod的可用的CPU列表。例如，當前Node節點預留CPU:[0-1]，調度了一個獨享實例占用CPU:[2-3]，CgroupController會計算當前Node節點上的共享CPU=總的CPU-Node預留-獨享CPU，并將共享Pod全部綁定到共享CPU核心上。當再調度一個獨享pod，CgroupController會更新共享CPU核心，并刷新主機上所有共享POD綁定的CPU核心。

傳統的服務器部署MySQL實例有上限，RDS通過調整部署策略進行了突破，如獨共享混布，神龍ECS掛盤上限提升，調整IO策略等提升機器密度。通過技術手段節省一半的機頭數來部署小規格實例，進一步的提升部署密度，節約大促資源。

業務屬性反親和靈活調度

RDS提供更豐富的資源調度打散策略能力，滿足按照業務自定義屬性實現打散，進一步提升靈活調度能力。舉一個場景，在今年雙11前，集團的核心數據庫都在云上，但是集團對于不同的業務的數據庫有著不同的調度需求，例如交易庫必須獨占，庫存的數據庫必須單機兩實例。面對這個業務需求場景的時候，按照以往的調度邏輯，都是在集群資源池中來找最優解，這個邏輯肯定無法解決集團的業務調度需求，RDS針對這種場景在業務和資源調度層面增加反親和性資源調度標識，可以根據業務場景需求來實現單機業務屬性的靈活資源調度部署。

RDS內核特性

如何實現RPO=0？

阿里巴巴集團電商全部使用的是RDS三節點企業版，包括主節點（Leader）、備節點（Follower）、日志節點（Logger），通過Paxos協議做到RPO等于0。主要有幾個特性:

• Leader會把待提交的事務傳輸到其他節點，當達到多數派后在Leader節點上做事務提交；
• 當Leader Crash的時候，新的Leader節點會通過自己本地的日志+其他節點日志補全日志并回放完成后，會接受新的事務；
• 日志節點僅Binlog日志和一些基礎的數據字典信息，這樣做的好處是既能滿足Paxos協議的多數派，又能節省成本，和MySQL的MGR形成差異化。

如何跟蹤識別限流？

今年的雙11，RDS內核做了深度優化,特別是分庫分表級別的多點寫、Statement Queue及慢SQL限流這塊。針對業務系統大促態等特別業務場景，RDS在運行時短時間內突然收到大量的高資源占用的查詢請求(例如慢SQL或者OLAP類請求或者極高并發的burst流量),將會造成此時間段內RDS內部的線程池資源被耗盡而無法對其他請求進行服務,從而使得整體性能急劇下降,對業務造成巨大影響，整個過程如下：

RDS內核采用的線程池模型，當新Query需要獲取內核CPU資源時首先獲取線程資源, 進而由操作系統內核調度獲取CPU資源，而高消耗資源SQL的存在會導致新的SQL獲取到的CPU時間片少同時線程過多會導致難以獲取到CPU資源。

如上圖, 一個Work線程會同步等待Innodb的讀寫結果, 因此在Query IO時間內, 線程資源被當前Query占據。Worker線程數量限制為Thread_pool_size *Thread_pool_oversubscribe, 當有大量Slow Query到來占據線程池資源, 則后續請求無法進去Worker被執行(或者進入線程池后因為IO資源被Slow Query占用而導致IO 等待, 進而惡化線程池資源地釋放)。

為減輕Slow Query造成的負面影響,內核基于Statement Digest實現SQB的慢查詢檢測和限流功能，RDS管控進行了新的內核小版本發布，集團RDS實例全部升級到該版本，實現了100%實例覆蓋，進一步的提升性能和RDS穩定性。

Slow Query Blocker分為兩個子模塊: 慢查詢模式匹配過濾模塊和檢測模塊。

匹配過濾模塊將根據歷史上已發現的Slow Query模式列表, 對匹配上列表中任意模式且并發度達到設定并發度上線的的當前Query語句進行已定義的應對動作。

檢測模塊分為兩個部分：

在普通SQL語句執行之后, 判斷其是否是慢查詢, 是則插入到慢查詢模式列表中根據既定的Slow Query檢測策略, 周期性檢測Threadpool，測算運行Thread當前執行的Query語句是否超時(Slow Query)。 如果是, 則將當前Slow Query的模式記錄到模式列表中供過濾模塊使用. 根據自定義的Slow Query類型, 還可以自定義該類型Slow Query對應的限流動作，該動作將在限流模塊檢測到匹配的Query后執行。

內核開啟SQB限流功能后，能看到以下現象，對于業務正常的SQL是不受影響的，能正常的請求并獲取結果，而不會因為SlowQuery導致的線程池耗盡導致不可服務，進一步提升RDS的穩定性，最大限度的減少用戶業務的影響。

未來展望

目前各大云廠商都在進行RDS IPV6技術演進，我們也在快速迭代中，接下來集團部分業務會切到雙棧模式。同時，我們也在推進RDS國產化，目前已有部分集團電商交易業務國產化試點。在資源調度方面我們也在探索和推進大混部形態，更進一步的降低大促成本。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的双11特刊 | 云数据库RDS如何顺滑应对流量洪峰的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。