螞蟻金服雙11大促全面揭祕：深刻洞察OceanBase雲平臺

摘要：本文重點分享了在雙11背景下，OceanBase雲平臺所遇到的挑戰，介紹了針對實時監控和規模運維兩個方面雲平臺所提供的應對策略，並詳細解釋了須要作哪些設計才能夠解決這些挑戰？本文從開發者視角，帶你們瞭解構建大規模分佈式系統要關注的事情。

演講嘉賓簡介：

張松樹（花名：笑言）：現任螞蟻金服 OceanBase 團隊技術專家，2014 年加入阿里巴巴，曾是阿里雲 GTS 產品 Founder，從事領域涉及分佈式事務、中間件高可用，致力於分佈式系統穩定性的建設工做，目前主要負責 OceanBase 雲平臺的建設。

本次直播視頻精彩回顧，戳這裏！https://tech.antfin.com/activ...

如下內容根據演講嘉賓視頻分享以及PPT整理而成。

https://tech.antfin.com/activ...

本次的分享主要圍繞如下四個方面：

1、雙11帶來的挑戰

2、實時監控技術點剖析

3、極致運維技術點剖析

4、OceanBase雲平臺

1、雙11帶來的挑戰

剛剛過去的2018年雙11是阿里雙11的第十個年頭。從2009年開始，當時一天的營業額還不到1個億，可是到了2012年，營業額就已經增加到了191億。在這三年當中，除了逐年成倍增加的銷售數字，另外比較重要的事情就是OceanBase誕生了。2014年，OceanBase開始應用於支付寶的核心交易系統，當時OceanBase的版本是0.5版本，一個開源版本，你們最開始瞭解OceanBase就是從0.5版本開始的。到了2015年，將近1000億的日營收，螞蟻交易支付鏈路百分之百的流量都已經切到OceanBase上了。2016年雙11，支付寶的每秒支付峯值創造了12萬筆/秒的世界記錄。全世界比較大的交易系統有Visa和Master。Visa的支付峯值大概是5萬筆/秒，Master比Visa略少一些，因此12萬筆/秒是很是有記念意義的。2017年雙11，誕生了數據庫處理峯值4200萬/秒世界紀錄，2018年，OceanBase在存儲成本以及性能方面有了重大突破。

下面的漫畫生動地描繪了雙11前阿里技術人員的工做狀態。在雙11將要開始的一段時間，對於技術人員心臟的挑戰是很是大的。廣泛來講，每一年雙11從零點時刻開始，交易曲線會在很短的時間內衝到峯值，在峯值處很平穩的運行10分鐘左右，而後再掉下來。你們能夠思考一下，爲何會存在那段10分鐘左右的平穩期？這是由於系統容量不足以承載瞬時流入的海量請求，這時系統會採起一些自我保護手段來保證系統不被壓垮，這也是分佈式高可用的一些特徵，作互聯網應用的人會比較熟悉這一點。這些策略包括限流、預付、當天沒法退貨等，這是都是爲了保證系統的高可用而採起的措施。可是沒有用戶請求被限流，纔是最理想的購物體驗，這要求咱們的技術人員須要經過技術手段來不斷提高用戶的購物體驗。

雙11具體會給OceanBase帶來什麼挑戰呢？

首先看系統高可用，簡單來講，高可用就是可以時時刻刻提供一個持續穩定的服務。若是隻有幾百幾千人使用系統，高可用是很容易實現的。可是對於數十億用戶同時併發請求的狀況，如何維持如此大規模分佈式系統的高可用是一個很是挑戰技術深度的事情。來看OceanBase，目前OceanBase有數萬個的服務節點，這些服務節點分佈在阿里巴巴不一樣的數據中心。服務器部署在不一樣的地域會衍生出一系列問題，好比不一樣地域之間存在網絡延遲，北京到上海，大概有30-50毫秒的延遲。那麼咱們的數據庫須要儘量的保證事務操做不跨地域，以保證數據庫服務穩定。

還有實時計算和監控能力的問題，前面所提到的，4200萬條SQL在同一秒產生，每條SQL背後有大量、多維度的監控數據，監控信息散落到分佈式系統中，要給不一樣業務視角的同窗提供知足業務需求的數據，須要把這些散落在數萬個服務節點上數據快速發現、聚合、實時計算而且展現出來。這也是極具挑戰的。

另外，怎麼能作到全方位的安全？數據安全是系統的底線，不管是數據庫服務，仍是數據庫平臺都會將數據安全做爲系統建設的基本原則。

還有，如何作到極低的資源佔用？在作分佈式系統時，須要考慮資源問題。因爲幾萬臺服務器自己的成本是很是龐大的數字，咱們的用戶在進行技術選型的時候，成本是很重要的考慮因素，因此將系統資源發揮到它的極限對於工程師來講是極具挑戰的。

最後一個挑戰是系統要作到可定製可擴展。作業務系統時所能提供的功能很是有限，沒法預設到百分之百，也不可能匹配到全部用戶的需求，只能儘量的把系統作到用戶可自定義，站在用戶的視角來，把他們的問題解決掉。對於OceanBase來講，可定製可擴展是很是重要的問題，它須要給每個用戶提供專屬的數據庫操做體驗，用戶能夠經過接口或者服務，經過數據庫雲平臺作一些定製化的操做。

2、實時監控技術點剖析

一條SQL的一輩子

一個數據庫可以正確的執行SQL是最基本的功能。而對於OCP來講，這只是開始。分佈式系統與單機系統最大的區別是分佈式系統由多個服務器組成，那麼數據究竟在哪一個服務器節點上？一條SQL由哪臺服務器承擔執行任務？若是發生了問題，應該到哪一臺機器說查找數據，並解決問題？這些都是OCP關注的問題。OCP對租戶級和會話級的監控數據進行採集，包括監控項，等待事件和鎖事件。採集完以後對採集的數據從不一樣的視角進行聚合，給不一樣的業務人員提供知足他們視角的視圖。以後對數據進行分析，包括分析SQL性能，執行路徑等等，給用戶提供實際的建議。根據預設規則或者自定義規則，實時告警。這些流程是整個分佈式系統可以提供更好更穩定服務的必備環節。

實時監控-海量數據處理

下圖左邊是蜂窩狀的數據庫服務器，它會分佈在全國各地多個機房內。那麼該如何集中化處理這些數據？最簡單的方法是把他們採集到集中式的數據庫裏面，但隨之而來的問題就是不一樣地方的數據所經歷的延時不同。數據採集到數據庫裏面後，對於這些不是同一個時間段的數據如何提供統一的視圖？數據進行集中處理後，要作相應的加工，若是加工的鏈路足夠的長，足夠的耗時，那麼數據實時性就會遇到問題。並且對於數據所給出的建議功效也會大打折扣。因此須要採用高質量的算法和並行計算的策略解決這個問題。一樣，經過聚合的鏈路把數據進行分類，如建議事件，警告事件，普通事件等。採用不一樣事件處理流程解決不一樣的數據。

實時監控-監控信息

每一條SQL都會產生N個監控項，好比，4200萬條SQL背後的數據量是N*4200萬監控信息。在這種量級下，分佈式系統的開發人員重點關注哪些問題？以下圖，在系統級別下包括集羣，實例，主機，事務，IO，鎖和臨界區等指標。在SQL級別下由延時，返回行，CPU時間佔用，邏輯讀行數，物理讀的行數，內部等待和外部等待花費的時間等。如此多的數據就僅僅只是一條SQL下來所產生的數據。

做爲分佈式系統的構建者，面對如此多的數據，該採用什麼存儲方式？一般來講，主要有兩種存儲模型，一種是窄表模型，另外一種是寬表模型。對於窄表來講，一行信息裏面有兩個或三個字段，一條信息所包含的屬性比較少。寬表則相反，一行裏有比較多的屬性，少則幾十個，多則上百個。窄表典型的表明是HBase，寬表就是MySQL。他們的問題和優缺點也是顯而易見的。

好比說要統計一臺機器在某一個時間點的全部的信息，要在程序裏實現，在窄表模型下想要對這些信息作擴展，開發者說須要改代碼，而這種操做對於分佈式系統構建者是很是不友好的事情。最理想的是經過一條SQL或修者改一個列就能夠作到信息擴展，因此寬表模型對於維護成本相對較低。

可是在另外的問題上，寬表模型的擴展性並無那麼好，好比想要加一個屬性，可能還須要考慮加到哪張表，字段須要什麼描述方式。這時窄表就具有擴展性的優點。在表結構變動時，好比1個TB數據的表，加一個字段是很難想像的。

OceanBase是一款準內存數據庫，中間數據保存在內存中，週期性和基線數據作合併，所以DDL不會產生鎖表問題；OceanBase採用了高效的壓縮算法，儘量的很好的解決了經濟性的問題。同時，使用OceanBase不須要額外部署資源，對於提高構建系統的效率無疑是重大利好。

3、極致運維技術點剖析

近幾年分佈式系統發展特別快，包括阿里、AWS都已經有了成熟的全鏈路監控跟蹤系統，OCP也同樣。

每一條SQL或者事務都會有個全局惟一的Transaction ID，能夠幫助DBA和運維人員根據Transaction ID到數據庫的服務器中抓日誌、查問題；DBA和運維人員還利用OCP上提供的一系列服務作運維相關的工做，包括集羣管理、計算邏輯編排、流程控制等。OCP對每一次的操做都會有一個全局的Request ID來全鏈路跟蹤該操做所通過的每個環節；Transaction ID表如今數據庫層面，Request ID表如今平臺服務層面，做爲開發者，可以結合業務，作完整業務的全鏈路是咱們下一步要關心的事情。

數據庫的使用者比較關心的是數據庫的增刪改查，而對於OCP實現者來講，還須要對數據庫進行監控、運維、調度，提供數據服務、數據管理、數據庫診斷等。OCP提供了Open-SDK的方式，讓每一個人均可以根據本身的需求以及喜愛來定製本身的數據庫。

4、OceanBase雲平臺

下面看看Oracle雲是怎麼作的。最底層，Oracle數據庫服務跑在雲主機上，有多是公有云（如阿里雲，AWS、騰訊雲）；多是專有云，大型的企業用戶可能會自建機房，將數據庫服務部署在自建機房裏；也多是混合雲，將自建機房和公有云作打通，數據在專有云裏面，而後管控和服務在公有云上。中間層，Oracle會把數據管理，應用集成等基礎的能力包裝成服務發佈給開發者。最上層，將會有不一樣的業務視角提供給不一樣角色。

下圖是阿里內部的OCP的構建模式。底層是由物理機，ECS，Docker等組成的基礎設施層;上面是OceanBase數據庫；OceanBase之上構建了OCP平臺以及各種平臺服務。OCP從功能上來講包括監控、運維、診斷、資源調度等基礎應用，另外還有數據遷移、備份恢復、歷史庫等數據管理類應用。服務之上，構建了Open-SDK，將服務能力經過SDK的方式發佈出去，SDK可以幫助你們跟本身的業務系統作結合。最上面提供了不一樣的業務視角，好比開發人員會關心一個數據庫實例的狀態，用戶DBA會關注本身的集羣運行狀態，系統的DBA要從更宏觀的層面關心全部系統之間負載是否均衡，穩定性是否好。

現狀

下圖是目前OceanBase雲平臺所應用的場景，客戶包括螞蟻金服，網商銀行，南京銀行，浙商銀行等等。右邊是阿里巴巴內部應用的場景，OceanBase在集團內獲得了普遍的應用。OceanBase是通過了8年的驗證磨練出來的成熟的產品。然而云平臺成長的時間並不長，還處於初級的階段。咱們的初級目標是系統變得更穩定，功能更友好。對比Oracle，內核研發人員是幾千人，可是Oracle公司其實有幾萬人。他們有大量的人都投入到了工具，平臺，致力於怎能讓數據庫從使用的感知更友好，這是咱們OceanBase雲平臺所關注的事情。

點擊閱讀更多，查看更多詳情