【複盤】從肩挑背扛到99%聚石塔訂單，AliCloudDB四年雙11技術突破！

2015年天貓雙11購物狂歡節已經完美落下帷幕，高峰期間訂單建立每秒達到了14萬筆（達每秒14萬筆），總訂單量達到了4.78億，技術名額再次重新整理世界紀錄。其中99%的訂單通過聚石塔訂單推送，并在阿裡雲雲資料庫服務（aliclouddb，曾稱rds）中完成存儲和處理。在持續高壓力沖擊下，整個雙11期間aliclouddb表現堅如磐石：

高峰期間叢集的總qps達到了近300w每秒；

單個商家最高處理訂單的能力超過400萬單；

百萬商家在aliclouddb上穩定運作，全網實作了0故障，0丢單。

華麗數字的背後，作為整個天貓商家背景資料庫的基石，aliclouddb是如何保障在零點洪峰來臨時候穩定、安全和順暢？如此龐大規模的資料庫執行個體叢集又是怎樣一步步成長起來的？“雲栖社群”特别邀請連續4年支援天貓雙11的aliclouddb團隊核心專家玄慚，深入分享這4年雙11背後的aliclouddb是如何實作技術突破的。

下為玄慚的分享：

<b>圖：天貓雙11</b><b>背後的“</b><b>護航俠”——阿裡雲資料庫</b><b></b>

<b>2012</b><b>，肩挑背扛和逐個優化</b>

2012年是阿裡雲資料庫支撐雙11天貓商家背景核心資料庫的第一年。其承擔了天貓20%的訂單量。如果用一個關鍵詞來形容2012年的雙11，那就是肩挑背扛。阿裡雲資料庫從9月份開始對外提供服務之後，有很商家就選擇将本地資料庫遷移上雲。但是在遷移過程中，其遇到了一個非常大的問題。當時阿裡雲資料庫支援mysql和sqlserver兩類引擎。這兩類資料庫的上雲遷移都不支援線上，以緻使用者的業務停機時間（會）非常長。同時遷移過程很容易受網絡影響而出現中斷。該問題在sqlserver上尤為突出。記得有一個使用者由于資料量特别大，為了加快遷移速度，其甚至把硬碟郵寄給了我們。是以幫助使用者遷移資料庫上雲的工作就落到了dba身上。那個時候，阿裡雲資料庫短短一個月内幫助使用者手工遷移了數百規模的資料庫執行個體到雲上。

現在這個問題已經不再存在。資料庫遷移已經通過dts線上遷移工具來完成資料庫上雲的遷移工作，以最大程度地降低業務停機時間。除了資料遷移，dts目前還支援資料訂閱及資料實時同步。底層使用資料流基礎設施為阿裡雙11異地雙活基礎架構，為數千下遊應用提供實時資料流，已線上上穩定運作達3年之久。使用dts可以輕松幫助雲使用者建構安全、可擴充、高可用的資料架構。

而談到2012年雙11備戰，記憶猶新。雙11的前一個月，阿裡雲資料庫團隊白天要準備資源和雙11所有工作，夜裡還需要協助使用者将資料庫遷移上雲。彈性更新需要對執行個體逐個進行更新，商家的資料庫也需要逐個進行優化，并為商家提出優化建議。天貓雙11能否扛過零點高峰？我的心裡是打鼓的，但結果讓我們深受鼓舞。完全ok。而後幾年，我們不斷打磨産品，沉澱出了衆多的産品需求：例如上雲遷移，資源自動擴容，收容和離散，性能診斷自動化等。在我們看來，隻有把雙11的經驗和能力産品化，才是真正長遠發展之計。

<b> </b>

<b>2013</b><b>，指數增長和資料鍊路改造遷移</b>

2013年是阿裡雲資料庫支撐雙11商家背景核心資料庫的第二年。其承擔了天貓50%的訂單量。如果用一個關鍵詞來形容2013年的雙11，那就是變化。第一年雙11執行個體規模量不是很大，然而2013年的雙11執行個體數規模則是成指數級别增長。原來的資料通路鍊路層的容量已經不能再支援如此規模的使用者量。是以我們開始對資料鍊路通路層進行改造遷移。改造遷移過程的時間點與雙11的備戰時間點重合，由此觸發了非常多的變化，給雙11的備戰工作造成了很大的壓力。一路拼搏，終于在雙11之前把鍊路架構穩定下來。雙11當天，記憶尤深的是下午6點左右出現的驚心動魄的場面。由于一個使用者發送了超大長度的sql到阿裡雲資料庫，同時由于proxy本身問題，是以整個proxy叢集出現異常。雖然問題很快得到了處理，影響可控，但給我們敲響了警鐘——2014年要重點把資料鍊路中間層穩定下來。這一年中，我們挑戰很大，經驗也得到很多：

sqlserver支援備份檔案ftp導入，解決了2012使用者上雲的問題；

實作了io，cpu的資源隔離，解決了大部分執行個體間資源争搶問題；

全鍊路壓測引入rds雙11，檢驗rds各個元件容量，從中發現問題并解決。

<b>2014</b><b>，注入攔截保證安全和資料庫優化</b>

2014年的雙11，阿裡雲資料庫在經曆了兩年的成長期之後開始迎來成熟。汲取了2013年資料鍊路改造的慘痛教訓，我們在雙11前統一了所有叢集的資料鍊路通路。在支援靈活資料鍊路通路模式，高安全鍊路通路模式下，實作了sql注入的攔截功能，幫助使用者更簡單地防護資料庫的安全，避免資料庫被注入攻破。雙11當天表現平穩。承擔了天貓96%的訂單量。叢集qps峰值達到142w。叢集rds執行個體數也達到了曆史新高。

縱觀2014年雙11，雖然系統已經趨于穩定，但是人工參與度依然較高。團隊投入了較多的人力資源來幫助商家的資料庫進行優化。同時雙11擴容的資源并沒有完全下線，也造成了部分叢集資源的空閑。是以這兩個問題抛給了2015年雙11。

<b>2015</b><b>，資源自動離散與收容和自動化診斷</b>

2015年叢集的規模越來越大，雙11我們為叢集預備了2-3倍容量資源供使用者彈性更新使用。為了使新上線的機器得到資源最大化利用，以保障系統的穩定，需要将老機器上的執行個體離散到新機器上。同時雙11活動完後我們需要把這一批擴容的主機下線，将其補充到其他業務叢集進行售賣，以實作資源使用率最大化。針對上面的兩個應用場景，rds啟動了移山項目。移山離散政策着力于對主機以及執行個體最近的性能資料進行計算，得出需要遷移離散的執行個體清單。移山收容政策則對叢集和主機的性能資料進行計算，進而得出需要收容的主機執行個體清單。

雙11期間，移山共完成了數千次的資源離散任務，極大程度上節約了人力成本，為雙11的資源穩定奠定了堅實基礎。雙11後我們快速下線掉擴容的機器資源，補充到其他業務叢集繼續售賣。這實作了資源最大化利用，使資源真正地“流動”了起來。

在往年雙11備戰期間，雲dba團隊需要投入大量的人力對商家的資料庫進行優化。随着執行個體規模數的上漲，這種人工的支援方式顯然是不可持續的。在2015年，我們不斷将雲dba的診斷優化經驗進行總結歸納，并開發完成了clouddba診斷引擎。該診斷工具在今年雙11帶來了極大的生産力解放。大量客戶的性能問題通過clouddba的建議得到了很好的解決：

壓測期間，使用者共觸發210次性能診斷任務，産生2546條優化建議；

雙11期間，clouddba診斷引擎服務所有的rds執行個體，共産生優化建議37713條；

經過多輪索引推薦算法優化，并引入代價模型，語句重寫等技術後，mysql索引推薦準确率超過90%；

目前clouddba診斷引擎支援索引推薦、空間診斷、隻讀執行個體延遲診斷等功能。rds的使用者可以在阿裡雲控制台、dms上擷取診斷資訊。目前已經有不少雲使用者學會了如何通過診斷引擎進行自動優化，使sql診斷不再成為難事。

除此以外，還有異地災備的産品化也非常值得分享。2015年rds為天貓的商家背景資料庫提供了異地災備的功能。當主機房出現較大的負載壓力、斷網、斷電等極端情況，rds可将商家的背景系統在30分鐘内切換至災備機房繼續運作，以保障總體可靠性，進一步確定平台大型品牌商家雙11期間背景系統安全、穩定。今年雙11當天出現了一個小插曲恰好用到了這些。一家大型商家的資料庫出現了性能抖動，原因是背景的訂單報表系統極其複雜的sql拖垮了主庫的性能。sql出現堆積，cpu達到100%。此時優化sql的效果非常有限。我們想到了異地災備節點。災備節點的資料同步和主庫基本是實時的。是以當時我們就建議使用者将這個訂單報表系統切換到災備執行個體上去查詢資料，以此來減小主庫的壓力。這個方法很成功。

<b>未來，走出去傳承最佳實踐和保障經驗</b>

還記得2012年一家天貓服務商和我說：“今年遇到了一群靠譜的人，在加上靠譜的技術，才能夠一起做靠譜的事情。”這句話一直激勵着我。我們也相信，能夠真正地幫到商家，是對這次參與雙11所有人的最大回報。

從上雲肩挑背扛到線上遷移，讓上雲不再成為難事；

從資源手工離散和下線到自動化擴容和收容，讓資源真正流動起來；

将診斷經驗沉澱為自動化診斷工具，讓診斷不再成為難事。

一幕又一幕，我們始終堅信隻有把雙11的經驗和能力産品化和工具化，利用雙11這樣極具挑戰的項目不斷錘煉我們的産品，才是真正長遠發展之計。曆經4年發展，aliclouddb在穩定性以及産品功能的豐富上不斷進步。未來，我們希望能夠出去多走一走，接近雲使用者，多多傾聽他們的聲音，将最佳實踐和保障經驗傳承給使用者，幫助他們一起把系統穩定性保障起來，是我們最大的心願。

—————————————————————————————————————

任何資料庫技術問題，都找雲栖社群資料庫團隊，大牛都在這裡！