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

**演講嘉賓簡介：**

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

本次直播影片精彩回顧，[戳這裡](https://yq.aliyun.com/video/play/1291)！https://tech.antfin.com/activities/41/review/54

**以下內容根據演講嘉賓影片分享以及PPT整理而成。**

https://tech.antfin.com/activities/41/review

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

一、雙11帶來的挑戰

二、實時監控技術點剖析

三、極致運維技術點剖析

四、OceanBase雲平臺

# 一、雙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在儲存成本以及效能方面有了重大突破。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142627537.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
下面的漫畫生動地描繪了雙11前阿里技術人員的工作狀態。在雙11將要開始的一段時間，對於技術人員心臟的挑戰是非常大的。普遍來說，每年雙11從零點時刻開始，交易曲線會在很短的時間內衝到峰值，在峰值處很平穩的執行10分鐘左右，然後再掉下來。大家可以思考一下，為什麼會存在那段10分鐘左右的平穩期？這是因為系統容量不足以承載瞬時流入的海量請求，這時系統會採取一些自我保護手段來保證系統不被壓垮，這也是分散式高可用的一些特徵，做網際網路應用的人會比較熟悉這一點。這些策略包括限流、預付、當天無法退貨等，這是都是為了保證系統的高可用而採取的措施。但是沒有使用者請求被限流，才是最理想的購物體驗，這要求我們的技術人員需要透過技術手段來不斷提升使用者的購物體驗。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142639132.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)

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

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

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

另外，怎麼能做到全方位的安全？資料安全是系統的底線，無論是資料庫服務，還是資料庫平臺都會將資料安全作為系統建設的基本原則。

還有，如何做到極低的資源佔用？在做分散式系統時，需要考慮資源問題。由於幾萬臺伺服器本身的成本是非常龐大的數字，我們的使用者在進行技術選型的時候，成本是很重要的考慮因素，所以將系統資源發揮到它的極限對於工程師來說是極具挑戰的。

最後一個挑戰是系統要做到可定製可擴充套件。做業務系統時所能提供的功能非常有限，無法預設到百分之百，也不可能匹配到所有使用者的需求，只能儘可能的把系統做到使用者可自定義，站在使用者的視角來，把他們的問題解決掉。對於OceanBase來說，可定製可擴充套件是非常重要的問題，它需要給每一個使用者提供專屬的資料庫操作體驗，使用者可以透過介面或者服務，透過資料庫雲平臺做一些定製化的操作。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142701451.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)

# 二、實時監控技術點剖析

**一條SQL的一生**

一個資料庫能夠正確的執行SQL是最基本的功能。而對於OCP來說，這只是開始。分散式系統與單機系統最大的區別是分散式系統由多個伺服器組成，那麼資料究竟在哪個伺服器節點上？一條SQL由哪臺伺服器承擔執行任務？如果發生了問題，應該到哪一臺機器說查詢資料，並解決問題？這些都是OCP關注的問題。OCP對租戶級和會話級的監控資料進行採集，包括監控項，等待事件和鎖事件。採集完之後對採集的資料從不同的視角進行聚合，給不同的業務人員提供滿足他們視角的檢視。之後對資料進行分析，包括分析SQL效能，執行路徑等等，給使用者提供實際的建議。根據預設規則或者自定義規則，實時告警。這些流程是整個分散式系統能夠提供更好更穩定服務的必備環節。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142725465.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
**實時監控-海量資料處理**

下圖左邊是蜂窩狀的資料庫伺服器，它會分佈在全國各地多個機房內。那麼該如何集中化處理這些資料？最簡單的方法是把他們採集到集中式的資料庫裡面，但隨之而來的問題就是不同地方的資料所經歷的延時不一樣。資料採集到資料庫裡面後，對於這些不是同一個時間段的資料如何提供統一的檢視？資料進行集中處理後，要做相應的加工，如果加工的鏈路足夠的長，足夠的耗時，那麼資料實時性就會遇到問題。而且對於資料所給出的建議功效也會大打折扣。所以需要採用高質量的演算法和平行計算的策略解決這個問題。同樣，透過聚合的鏈路把資料進行分類，如建議事件，警告事件，普通事件等。採用不同事件處理流程解決不同的資料。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/2019031414273480.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
**實時監控-監控資訊**

每一條SQL都會產生N個監控項，比如，4200萬條SQL背後的資料量是N*4200萬監控資訊。在這種量級下，分散式系統的開發人員重點關注哪些問題？如下圖，在系統級別下包括叢集，例項，主機，事務，IO，鎖和臨界區等指標。在SQL級別下由延時，返回行，CPU時間佔用，邏輯讀行數，物理讀的行數，內部等待和外部等待花費的時間等。如此多的資料就僅僅只是一條SQL下來所產生的資料。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142743767.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
作為分散式系統的構建者，面對如此多的資料，該採用什麼儲存方式？通常來說，主要有兩種儲存模型，一種是窄表模型，另一種是寬表模型。對於窄表來說，一行資訊裡面有兩個或三個欄位，一條資訊所包含的屬性比較少。寬表則相反，一行裡有比較多的屬性，少則幾十個，多則上百個。窄表典型的代表是HBase，寬表就是MySQL。他們的問題和優缺點也是顯而易見的。

比如說要統計一臺機器在某一個時間點的所有的資訊，要在程式裡實現，在窄表模型下想要對這些資訊做擴充套件，開發者說需要改程式碼，而這種操作對於分散式系統構建者是非常不友好的事情。最理想的是透過一條SQL或修者改一個列就可以做到資訊擴充套件，所以寬表模型對於維護成本相對較低。

但是在另外的問題上，寬表模型的擴充套件性並沒有那麼好，比如想要加一個屬性，可能還需要考慮加到哪張表，欄位需要什麼描述方式。這時窄表就具備擴充套件性的優勢。在表結構變更時，比如1個TB資料的表，加一個欄位是很難想像的。

OceanBase是一款準記憶體資料庫，中間資料儲存在記憶體中，週期性和基線資料做合併，因此DDL不會產生鎖表問題；OceanBase採用了高效的壓縮演算法，儘可能的很好的解決了經濟性的問題。同時，使用OceanBase不需要額外部署資源，對於提升構建系統的效率無疑是重大利好。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142753423.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)

# 三、極致運維技術點剖析

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

每一條SQL或者事務都會有個全域性唯一的Transaction ID，可以幫助DBA和運維人員根據Transaction ID到資料庫的伺服器中抓日誌、查問題；DBA和運維人員還利用OCP上提供的一系列服務做運維相關的工作，包括叢集管理、計算邏輯編排、流程控制等。OCP對每一次的操作都會有一個全域性的Request ID來全鏈路跟蹤該操作所經過的每一個環節；Transaction ID表現在資料庫層面，Request ID表現在平臺服務層面，作為開發者，能夠結合業務，做完整業務的全鏈路是我們下一步要關心的事情。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142807572.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
資料庫的使用者比較關心的是資料庫的增刪改查，而對於OCP實現者來說，還需要對資料庫進行監控、運維、排程，提供資料服務、資料管理、資料庫診斷等。OCP提供了Open-SDK的方式，讓每個人都可以根據自己的需求以及喜好來定製自己的資料庫。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/2019031414281658.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)

# 四、OceanBase雲平臺

下面看看Oracle雲是怎麼做的。最底層，Oracle資料庫服務跑在雲主機上，有可能是公有云（如阿里雲，AWS、騰訊雲）；可能是專有云，大型的企業使用者可能會自建機房，將資料庫服務部署在自建機房裡；也可能是混合雲，將自建機房和公有云做打通，資料在專有云裡面，然後管控和服務在公有云上。中間層，Oracle會把資料管理，應用整合等基礎的能力包裝成服務釋出給開發者。最上層，將會有不同的業務視角提供給不同角色。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/2019031414282881.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
下圖是阿里內部的OCP的構建模式。底層是由物理機，ECS，Docker等組成的基礎設施層;上面是OceanBase資料庫；OceanBase之上構建了OCP平臺以及各類平臺服務。OCP從功能上來說包括監控、運維、診斷、資源排程等基礎應用，另外還有資料遷移、備份恢復、歷史庫等資料管理類應用。服務之上，構建了Open-SDK，將服務能力透過SDK的方式釋出出去，SDK能夠幫助大家跟自己的業務系統做結合。最上面提供了不同的業務視角，比如開發人員會關心一個資料庫例項的狀態，使用者DBA會關注自己的叢集執行狀態，系統的DBA要從更宏觀的層面關心所有系統之間負載是否均衡，穩定性是否好。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142836829.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
**現狀**

下圖是目前OceanBase雲平臺所應用的場景，客戶包括螞蟻金服，網商銀行，南京銀行，浙商銀行等等。右邊是阿里巴巴內部應用的場景，OceanBase在集團內得到了廣泛的應用。OceanBase是經過了8年的驗證磨練出來的成熟的產品。然而云平臺成長的時間並不長，還處於初級的階段。我們的初級目標是系統變得更穩定，功能更友好。對比Oracle，核心研發人員是幾千人，但是Oracle公司其實有幾萬人。他們有大量的人都投入到了工具，平臺，致力於怎能讓資料庫從使用的感知更友好，這是我們OceanBase雲平臺所關注的事情。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190314142849909.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDMyNjU4OQ==,size_16,color_FFFFFF,t_70)
 點選[閱讀更多](https://tech.antfin.com/articles?chInfo=zh)，檢視更多詳情

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

相關文章