2020年天貓雙十一成交額突破4982億，在雙十一走過12個年頭之際，咱們的訂單建立峯值達到58.3萬筆/秒，再次刷新全球在線交易系統的記錄。歷年雙十一都是對技術人的一次大考，峯值的絲般潤滑體驗是你們一致的追求，而數據庫可謂關鍵。多年雙十一大促「磨練」出阿里巴巴DBA一整套技能來應對大考，比方說全鏈路壓測、容災預案、實時限流等，同時阿里的數據庫產品能力也大幅提高，如智能化的企業級MySQL內核AliSQL，自研PolarDB引擎等，這些硬核能力是阿里巴巴集團數據庫團隊應對大考的底氣。數據庫
在數據庫引擎技術能力不斷攀登高峯的同時，長期以來咱們「彷佛忽略」一個很是重要的因素，而該因素倒是中大型企業上雲的必須考量點。若是將時鐘指針撥回到半年前，這個重要因素就擺在眼前，是阿里巴巴集團全部的數據庫系統全面上雲及雲原生化過不去的「坎」，它是什麼呢？服務器
1、阿里集團數據庫全面上雲的挑戰
當DBA維護的系統上百套甚至上萬套之後，系統管理的複雜度就會急劇上升，加上資源利用效率、業務高峯支持（如大促活動評估）、流量管理等上級或業務方「強加給」DBA的工做後，整個系統複雜度就會居高不下，這種複雜度「熵」就會指數級增加，而且沒法經過擴充DBA人數來有效解決問題，DBA自身也會陷入到繁雜的平常支持和「滅火」中，自身價值難以體現，這就是深坎。網絡
阿里巴巴集團就是這樣一個巨型的、系統複雜度「熵」奇高的大型企業。今年阿里雙十一要求全部系統全面上雲，相比單純提高系統吞吐擴展能力的技術要求，這個任務更加難完成。簡述下當初面臨的嚴峻挑戰：架構
1.如何保證大量數據庫短期內快速上雲？
這不只僅是數據的搬遷過程，還要在此期間支持業務需求，比方說如何作到對業務「無感知」的遷移數據上雲。如何在阿里的巨型體量下，保障全部系統全面上雲的絲般順滑度？框架
2.如何高效支持DBA知足雙十一期間的數據庫業務需求？
DBA對業務系統是熟悉，多系統之間有的相互依賴有的相互排斥，如何有效的將它們編排好，從而總體利用好數據庫資源，這是很是大的挑戰。分佈式
3.全面上雲之後，要支持DBA依舊對數據庫的強管理能力，比方說可以及時登陸操做系統排查數據庫問題等。性能
2、全面上雲的新打法，以專屬集羣RDS構建超高效數據庫管理體系
在全面上雲這個殘酷指標下，必須找到全新的方法來解決上述三個重點問題，構建一個高複雜度的但「混亂熵值」很低的超高效的數據庫管理體系。這就是全面採用專屬集羣RDS的根本前提。測試
那麼咱們是如何極短期內全面上雲而且可以絲般順滑，如何充分發揮DBA的業務把控能力從而實現對RDS標準化服務的超高效能的管理，以及如何利用專屬集羣的源生內核能力構建全球最大的異地多活電商系統呢？優化
2.1 絲般順滑上雲阿里雲
要實現絲般順滑上雲，須要充分規劃和精細的執行。因爲阿里集團是隔離於公有云的網絡環境，底層對數據庫資源的網絡配置上雲後都會涉及變化，數據庫還要特別注意避免雙寫，要和業務作聯動的流量管理。
上圖是咱們實現絲般順滑上雲的基礎框架圖：
1.將數據傳輸路徑儘可能縮短，節省大量時間：因爲阿里集團超高業務量，幾乎每一個數據庫系統的數據量都是巨大的，少則TB多則PB爲單位，咱們採用最原始有效的方法，將備份文件拷貝到雲上環境，而後執行快速恢復。
2.有效快速恢復是另外一省時環節。阿里集團數據庫廣泛有兩種存儲類型，分別是本地SSD盤和ESSD雲盤，二者的備份方案是不一樣的，本地SSD盤相似於Xtrabackup執行物理的備份，ESSD雲盤採用存儲級快照備份。對應的二者快速恢復的方法也不一樣，本地SSD盤在備份時採用庫表級備份，而恢復的則採用並行表級恢復，大幅度的提高恢復速度，ESSD雲盤則經過秒級快照恢復實現。也就是說從阿里集團網的全量備份、到數據兩套環境的傳輸、到雲上環境的快速恢復是一個聯動的連續過程，從而大大節省恢復時間。
3.利用MySQL源生複製實時追加增量數據，確保業務對數據的搬遷無感知。在複製技術方面，AliSQL 針對高延遲網絡作了大量的協議優化嘗試和測試，經過合理的Batching和Pipelining，設計並實現了一整套自適應的針對高延遲高吞吐和低延遲高吞吐網絡的通訊模式，極大的提高了日誌傳輸的性能。另外爲了節省帶寬，對binlog全面壓縮，同時在壓縮率和解壓速率上採個較好的平衡值。
4.統一的混合網絡環境代理實現流量的按需切換，確保業務感受遷移的過程是順滑的。聯動於業務部署，先切換讀流量到雲上環境，後切換寫流量。因爲代理層實現透明切換能力，在分鐘級級內會保持原有的數據庫鏈接，保障切寫過程當中業務是無感知的，在絕大數狀況下效果很好。
2.2 靈活可控的標準化服務管理
雙十一涉及數據庫系統數萬套，除交易、商品、用戶、評價、優惠、店鋪、積分等核心系統外，還有各類「中小型」業務系統，機會每一個業務都有一套或多套數據庫，每一個業務之間有親和性或排斥性需求，即必需要在專屬集羣中知足多樣性的業務部署要求。
舉例而言，咱們將購物車數據庫和購物車應用自身部署在一塊兒，確保購物車不受別的業務影響，同時購物車內部實現交叉部署，大體部署圖以下所示，經過靈活的部署策略，業務方DBA能夠制定一套複雜部署策略知足業務須要。
如上所述參與雙十一的業務方特別多，而DBA人數有限，DBA對業務的掌控程度也是高低不一的。通常而言，上述的核心業務基本上比較清晰，這主要得益於雙十一前的一次次全鏈路壓測，交易核心鏈路業務模型比較清晰，對數據庫容量的預估會很準確。可是這並非全部狀況，比方說創新型業務，對業務流量評估會很是的不許確，可能百倍增加也有多是百分比增加，此狀況下DBA預留數據庫資源沒有參考依據，如何在有限的資源中支持足夠多的創新型業務絕對是一大挑戰。再比方說原邊緣型業務，會因爲其餘系統的新依賴、或者業務流量徒增致使流量預期不許，更常見的是被其餘系統新依賴，還容易致使故障。
爲了解決該不肯定性問題，咱們在專屬集羣上特別開發智能化DAS資源調度系統，DBA能夠經過簡單的設置實例的彈性策略，DAS會根據過去系統的表現狀況以及突發狀態，基本上以準實時的方式實現秒級資源彈性，分鐘級資源調度。秒級資源彈性能力，是在整臺主機範圍內靈活的對實例資源進行調整，也能夠人工干預保護一些實例資源不被爭搶。分鐘級的資源調度能力，這得益於存儲計算分離架構，經過分佈式存儲的秒級快照能力，以分鐘級在不一樣主機之間從新平衡資源利用調度實例，因爲高可用保障系統和代理透明切換能力，這個過程幾乎是平滑的。經過專屬集羣，DBA只須要投入必定量的服務器資源，而後專一監控總體集羣的資源水位，就能夠保障大量的創新和小型業務的大促性能須要，可謂一夫當關萬夫莫開。
2.3 構建源生異地多活
雙十一零點高峯流量是巨大的，今年交易筆數達到58.3 萬筆/秒，數據庫集羣的TPS超過千萬級每秒，巨大的洪峯流量經過阿里的單元化數據庫部署來分流，從而規避單個實例單個機房的流量風險。與往年相比，今年單元化數據庫所有采用全球數據庫模式支持多地域的讀流量，另外在內核中實現源生多寫能力，支持實例集羣級別的異地多寫多活，從而能夠在不一樣地域分擔寫流量。
如上圖所示本次雙十一阿里巴巴啓用張北、深圳、南通3個地域，針對每一個Region是獨立開服的，地域之間是低耦合的，經過一個橋樑把他們鏈接起來，它就是全球數據庫網絡，（GDN，Global database network）。部署於不一樣地域的數據庫，採用MySQL的源生複製技術，保證數據的一致性和實時性。
關於異地多活，第一次實現了在內核層的雙向同步，在多個地域中都有各自主節點和備節點，在內核中實現雙向複製，保障兩個地域在數據總量上是一致的，同時寫實現分地域分流。這裏須要強調的一點，異地多活須要業務的改造，好比這個UID的數據只會在某一個地域寫入避免性衝突，此外ID（PK鍵）也須要使用獨立的Sequence，從而實現全局的一致性。業務和數據庫在本套架構中實現完美結合，業務只須要關注邏輯的拆分，而數據庫自身實現數據的同步組合，底層數據同步複雜性徹底由數據庫自身實現。
3、展望
總結而言，本次雙十一爲了保障集團數萬數據庫的全面上雲及雲原生化，咱們基於專屬集羣作了不少定向改造和匹配，取得了很是好的效果。核心交易鏈路總共構建數千臺機器集羣，總共超過數萬的數據庫節點，而且全部數據庫系統RPO等於0，主備延遲作到毫秒級，並保證總體人力效能數量級提高。靈活調度、源生複製等定製化能力，在專屬集羣內部實現產品化，通過雙十一驗證後，逐步開放，將會大幅度提高企業數據庫管理生產力，敬請期待。
做者：阿里雲高級技術專家 改天、阿里雲高級產品專家 勝通
本文爲阿里雲原創內容，未經容許不得轉載。