​簡介：從綠色低碳到硬核科技，看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核心。

​

業務屬性反親和靈活排程

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內部的執行緒池資源被耗盡而無法對其他請求進行服務,從而使得整體效能急劇下降,對業務造成巨大影響，整個過程如下：

​

如上圖, 一個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分為兩個子模組: 慢查詢模式匹配過濾模組和檢測模組。

​

檢測模組分為兩個部分：

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

核心開啟SQB限流功能後，能看到以下現象，對於業務正常的SQL是不受影響的，能正常的請求並獲取結果，而不會因為SlowQuery導致的執行緒池耗盡導致不可服務，進一步提升RDS的穩定性，最大限度的減少使用者業務的影響。

​

未來展望

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

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​