螞蟻金服天街：螞蟻雙11大促OceanBase核心技術全解析

演講嘉賓簡介：田啓傑（花名：天街）

現任螞蟻金服高級技術專家，2012年加入OceanBase 團隊，曾五次做爲OceanBase負責人承擔雙11大促保障工做，致力於OceanBase 提供高可用/高性能/低成本的數據庫服務，在數據庫相關技術及業務大促保障上有多年的沉澱和積累。

本次視頻精彩回顧，戳這裏！如下內容根據演講嘉賓視頻分享以及PPT整理而成。

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

1. 2018 OceanBase大促概述
2. 百萬支付&OceanBase2.0
3. 容器化
4. 平臺智能化
5. 將來發展規劃

1、2018 OceanBase大促概述

對於OceanBase數據庫而言，在大促面前須要面對來自容量、穩定、成本、效率、壓測和彈性這6個方面的挑戰：

容量。如何支撐全國人民一塊兒去買東西是一個難題。容量方面主要能夠分爲兩個點，數據庫單機性能和某一個集羣的容量，而這兩點不管在哪個層面上都要考慮大促的需求。單機性能指的是在大促壓力下，數據庫單機可否知足某個業務的需求；而集羣容量則須要綜合考慮應用、網絡、機房的組合，爭取使成本降到最低。

穩定。穩定大於一切！高峯期的任何抖動均可能對用戶產生很大影響。

成本。在平時狀態下，每秒大約有8000人正在完成支付，但雙11須要支撐40多萬人併發進行支付，所以服務能力可能須要增加五六十倍，那麼，機器是否須要增長五六十倍呢？所以，須要思考可否使用盡可能少的機器來節省成本。除了大促商品優惠的成本，技術人員所須要考慮的最大成本就是機器成本。

效率。前幾年可能在每一年的六月份就要開始準備雙11，那時所投入的人力成本很大。而若是在一個月的時間內完成大促準備，就須要高效率。

壓測。若是大促的流量要翻五六十倍，那麼爲了保證增長新機器時不出問題，而且成本可控，就須要儘量模擬真實業務的工做壓力，把真實狀況下的熱點對數據庫的衝擊在壓測環境下模擬出來。

彈性。彈性指的是將全部服務，包括從前端入口、應用服務器、數據庫以及網絡，統統從本來的服務站點很快地遷移到一個全新的站點上面去的能力。此外，還須要在遷移的過程當中將本來一秒八千多的支付能力拓展到四十多萬的支付能力。

若是可以合理應對以上6點挑戰，那麼就可以在技術角度完美地支持和應對雙11大促。

OceanBase彈性化體系 基礎設施。基礎設施中包括網絡、存儲、內核以及機房。網絡指的是在雲環境下的XGW虛擬的網絡和VPC的網絡。存儲投在物理機或者ECS上面，高性能的ECS怎麼和DB的容器進行結合。操做系統的能力上從內核來看OceanBase是AIO，DIO，CPU的隔離以及CPU的share。機房的Mancore互聯，能夠認爲它是一個網絡的創新,其實是讓三個機房兩兩互聯，兩個機房之間任意一條網絡斷掉，都能保證至少有兩個機房是可以工做的。

基礎架構。基礎架構統一的基座是容器和資源，好比阿里雲公共的服務器。再往上是OceanBase自己在大促體系下的一些關鍵的屬性，好比租戶的拆百和分區，獨立異構的FO。FO是指拉起新的獨立的沒有任何運行關聯的庫讓業務恢復起來。第四個是三地五中心。而後是多副本架構，其中有提供具備讀寫能力的副本，提供只讀的副本以及只投票的副本，這種不一樣的副本類型結合OceanBase的彈性，再搭配進行工做。

能力沉澱。OceanBase作的一些服務站，比方說OCP，以及其餘一些模塊。能夠認爲將大促中提到的6個點的通用能力給抽象出來，而後和平常服務相結合，沉澱出通用的能力。

大促服務。無損壓測指的是作一些模擬壓測時保證對線上業務沒有任何影響，統一的思想就是隔離。隔離時要及時把壓測的流量熔斷掉，好比說把DB的水位，應用服務器的訪問的ID作一些預測。若是任務出來會掛掉的話，就要進行壓測，或者把資源在真實的在線庫和壓測庫之間作一個快速的遷移。極致彈性是指將全國100個UID中任意一個UID均可以彈到任意一個機構裏面去。一個瓶頸多是體如今機房上，與機房的用地，電力等不可突破的因素有關。若是能夠作到極致性，即可以體現一點，就是能夠將100個UID在大促時攤到100個不一樣的城市，從100個不一樣城市挑選100個機房來進行服務，因此它在可預見的範圍內是不會成爲瓶頸的。四小時建站，能夠在四小時以內在任意一個站點把支付寶的任意的服務都搬到上面去，包括數據，代理數據也能夠遷出去。

OceanBase彈性化體系

基礎設施。基礎設施中包括網絡、存儲、內核以及機房。網絡指的是在雲環境下的XGW虛擬的網絡和VPC的網絡。存儲投在物理機或者ECS上面，高性能的ECS怎麼和DB的容器進行結合。操做系統的能力上從內核來看OceanBase是AIO，DIO，CPU的隔離以及CPU的share。機房的Mancore互聯，能夠認爲它是一個網絡的創新,其實是讓三個機房兩兩互聯，兩個機房之間任意一條網絡斷掉，都能保證至少有兩個機房是可以工做的。

基礎架構。基礎架構統一的基座是容器和資源，好比阿里雲公共的服務器。再往上是OceanBase自己在大促體系下的一些關鍵的屬性，好比租戶的拆百和分區，獨立異構的FO。FO是指拉起新的獨立的沒有任何運行關聯的庫讓業務恢復起來。第四個是三地五中心。而後是多副本架構，其中有提供具備讀寫能力的副本，提供只讀的副本以及只投票的副本，這種不一樣的副本類型結合OceanBase的彈性，再搭配進行工做。

能力沉澱。OceanBase作的一些服務站，比方說OCP，以及其餘一些模塊。能夠認爲將大促中提到的6個點的通用能力給抽象出來，而後和平常服務相結合，沉澱出通用的能力。

大促服務。無損壓測指的是作一些模擬壓測時保證對線上業務沒有任何影響，統一的思想就是隔離。隔離時要及時把壓測的流量熔斷掉，好比說把DB的水位，應用服務器的訪問的ID作一些預測。若是任務出來會掛掉的話，就要進行壓測，或者把資源在真實的在線庫和壓測庫之間作一個快速的遷移。極致彈性是指將全國100個UID中任意一個UID均可以彈到任意一個機構裏面去。一個瓶頸多是體如今機房上，與機房的用地，電力等不可突破的因素有關。若是能夠作到極致性，即可以體現一點，就是能夠將100個UID在大促時攤到100個不一樣的城市，從100個不一樣城市挑選100個機房來進行服務，因此它在可預見的範圍內是不會成爲瓶頸的。四小時建站，能夠在四小時以內在任意一個站點把支付寶的任意的服務都搬到上面去，包括數據，代理數據也能夠遷出去。

2、百萬支付&OceanBase2.0

百萬支付目標

下圖展現每一年雙11峯值的能力和成交的筆數，十年來雙11峯值的攀升基本上是垂直上漲的曲線。在將來，峯值能力怎麼可以不成爲支付的瓶頸？好比目前只能支撐50萬人同時支付，那該如何打破這個瓶頸？將來可能須要有100萬人在每秒一塊兒進行工做。螞蟻提出了三年戰鬥百萬支付的目標，在高峯期，一秒鐘進行100萬的支付，同時一天能夠支撐1億訂單。

百萬支付瓶頸

支撐百萬支付目標要作什麼事情呢？從整個鏈路上來講的話，要看哪一份資源在擴展性上有瓶頸。擴展性上的瓶頸能夠認爲誰帶數據狀態，誰就是最難擴展的。其實是想利用的服務器是無狀態的，由於它沒有本身一個真實的業務屬性。那能夠認爲應用服務器的瓶頸就在於它所在的機房的瓶頸，因此服務器是不會成爲百萬支付的瓶頸的。那麼瓶頸只可能在數據庫上，由於一我的的數據只有一份，只能用在應用服務器，因爲應用服務器的服務能力是有上限的，如何打破上限？下面分別從性能和資源角度進行了討論。

性能。最小的數據分片性能已經達到了單機瓶頸，目前生成環境中最厲害的應用服務器大概是96C左右，實際上，2012年是32C，2016到了64C,到2018年已經用了96C。能夠看到32C到96C花了6年的時間，可是峯值從2012到如今已經翻了二十多倍。單純依靠硬件的疊加是不可取的，須要靠OceanBase支撐的數據庫的性能。

資源。資源異構和負載均衡。假設大促與十條鏈路有關係，十條鏈路的壓力是以金字塔尖倒置遞減的，入口處壓力最大，即建立交易的壓力最大。再往下是支付環節，其中有花唄，餘額寶，銀行卡等，隨着鏈路的延伸會有分力的做用，如花唄和銀行卡是使用獨立的資源進行部署，對於DB的壓力是降低的。不一樣的庫對應了不一樣鏈路，訪問的壓力是遞減的。隨着鏈路的延申，資源異構的差別化很大，意味着應用服務器的水位就會時高時低。在百萬支付場景下，百分之九十的資源都用來交易支付，剩下的資源很是少，如何打破的這個瓶頸，也是另外一個要解決的問題。

OceanBase2.0理念

OceanBase2.0的一個理念是針對性的解決數據分片的單機性能瓶頸。下圖中上面有一個DB,假設它服務全部的UID是00的支付寶用戶，00中有三張表，其中四有顏色，它們表明事務跨越三張表，三張表裏面任意一我的交易的時候所用到的數據在不一樣表中使用了相同的顏色。若是在交易時00庫扛不住了，傳統的方案落到DB就是分庫分表。新起一套庫，這套庫是原來容量的四倍，同時把原來三張表按照相同的規則分到獨立的庫中，再經過ElasticRule告訴底層路由從不一樣庫中讀取數據。可是分庫分表有幾個不友好的點，首先業務感知到了,因此要追溯到數據源。其次，應用統計上鍊路都是獨立的，沒法共享。還有數據庫拆分以後，可是縮容時是否是要保留四個最小規格，這即是長期存在現象的尾巴。最後，以前配套的工具都要進行改變。OceanBase2.0採起的方案是分區（Partition），數據庫的數目並無增長，可是能夠按照必定規則，將知足相同分區規則的數據聚合在同一個機器上。這可以很大程度上提升單機的性能，解決將來支付能力上升的瓶頸問題。

OceanBase2.0架構

那麼OceanBase2.0架構下的路由是怎麼工做的？一個服務器過來發給SQL，SQL傳給中間件，中間件提供路由功能，它把分庫分區表的規則作好，好比表級別的規則，DB級別的規則，彈性的規則以及分區的規則。中間件把分片的信息發送到OBClient, OBClient會製造一個生成列partition_id，發送給OBerver，由作一個分區裁剪。分區裁剪會精確地找到分片所在的DB上的應用服務器在哪裏。生成列與業務方綁定在一塊兒，從業務平常表的列中選取兩位最適合的作分片，孕育出來生成列的規則應用在表級別，全棧的表都採用這樣的規則。另外，分區規則的維護是一個固化的規則，OceanBase經過約束能力（constraint）提供分區裁剪能力，這時不要求中間件有分區裁剪能力，只要把約束定義好，把OceanBase調到最佳就能夠了。

百萬戰略基石

OceanBase2.0實現了彈性伸縮，也作到了業務無感和無損。業務無感是說DB作擴容時不須要感知到擴容。DB作擴容或者彈性時沒有業務失敗，叫無損。無損更多的是與OceanBase內核三節點的能力和作事務的能力綁定在一塊兒。極致高可用指的是要作到五個九，摺合下來一年不可用時間是52分鐘。首先經過故障隔離，任何單點故障之間是不會影響到另一臺服務器的。單點消除是說本來DB運行存在單點依賴，但如今將單點依賴上面的數據所有打散到不少的應用服務器上面就不會存在單點宕掉帶來的故障影響。第三是灰度能力，在應用變動或者版本更新時，灰度能力能夠作到只針對部分分片進行變動，影響範圍變得更小。資源的規格和負載均衡主要是原來滿負載的庫經過分區的方式分紅了統一的小塊，針對每一個小塊分配統一的資源。負載均衡最優的實踐就是平鋪，把壓力平鋪到全部服務器上。

3、容器化

爲何要進行容器化？

資源過剩。大促態下須要節省成本，成本體如今兩點。首先，減小應用服務器的數量，第二，下降持有服務器的時長。這兩個加起來就是大促成本，那如何解決資源總數的問題。第一種思路是性能優化，OceanBase2.0採起的就是性能優化，它在不提高機器數量的狀況下提高單機服務能力高達百分之五十。第二點是下降持有時長，高峯期前縮容，高峯期擴容，或者搶佔高峯期資源。下降持有時長理念的背後核心思想就是調度，把核心數據庫快速地調度到有資源的地方。這也是容器化的目的，容器化屏蔽了底層資源的差別，它隔離了底層資源，保證想要的資源。平常的服務器的資源每每都是過剩的。由於在每一階段對資源的訴求是不同的，不一樣業務的資源利用率是不一樣的。如何把總體資源進行統一是容器化要解決的問題。

資源負載。前面已提到了有長尾，碎片等問題。

資源規格。由於訪問帶來的資源分爲絕對資源和相對資源。業務有CPU和Disk存儲，CPU對不一樣業務的資源的差別很大，這是絕對資源的差別。相對資源差別是指一些業務消耗了CPU和Disk，另一些業務只消耗了CPU，CPU和Disk相對的差別就是相對資源差別。兩種資源都是資源規格要統一的問題。

機型和部署。每一年雙11採用的服務器機型都是不同的，服務器的資源異構的程度很大。須要把異構機型的能力發揮出來，這是容器化要解決的前提。每一年大促時，部署複雜度體現爲環境的複雜度，好比自建的機房，這些底層的部署差別反映到DB端帶來的問題是隨着業務的發展，對容災要求和查驗能力是存在差別的。不一樣部署須要有統一的解決方案。

容器化三個核心點

容器化是必要的。容器化中最關鍵的三點分別是規格歸一，資源隔離，搶佔和多緯調度。

規格統一。規格統一最重要的是分配，如UID，業務的分配。在進業務端入口時分紅資源進口分流，不會稱爲訪問的熱點。同時作業務改造，讀請求較高的時候加讀庫能夠下降壓力。經過資源規格歸一以後，定義出的無數規格能夠知足螞蟻全部資源的訴求。

資源隔離，搶佔。經過對資源進行分級變體，高分級業務能夠去搶佔低分級業務的資源，以保證穩定性。把資源放到對支付體驗有影響的資源上面。

多維調度。多維調度的範圍比較大，這裏的資源是廣義的資源，從業務入口一直到真實落到DB的過程當中以不一樣的資源維度進行調度。

OceanBase大促容器化架構

IaaS層。包括金融雲，阿里雲以及混合雲，在任何一個雲上都要構建容器化的架構。

調度層。一層是統一sigma調度，主要作統一資源規劃，生命週期的管理和資源彈性的規劃。二層是 kipp 和 OceanBase的調度，按照不一樣租戶的畫像信息，得出調度策略是平鋪，搶佔仍是資源親和。單機不超過 1% 的容災，經過資源親和，把一筆支付鏈路上所可以通過全部的應用和 DB調度在一個機器上，經過一個親和性標籤放在一塊兒，大大下降宕機的影響面。右邊是調度管控。

價值貢獻。頂層是容器化達到的價值貢獻，最大的貢獻是經過均衡資源利用率達到了價值翻倍。存區 & 存儲就近是指讓存儲節點和計算節點二者離得最近。

4、平臺智能化

爲何要作平臺智能化？

大促常態化。目前支付寶一年下來大促有十幾回，平均一月一次。大促的穩定性要求很高，流程性很強，那怎麼保證每月大促的平穩？傳統方法作簡單的擴容，成本浪費。因此要將大促的6個點固化，朝智能化方向走。

業務規模爆發。隨着業務規模爆發，要解決硬件存在的隱患，爲了知足業務的需求，傳統方式是行不通的。怎麼解決 10w+ 機器操做系統從 6U 升級到 7U？

穩定性。要達到 5 個 9目標，不能依賴於傳統平臺，只能靠智能平臺來作。

OceanBase 大促智能化實踐

擴縮容和Rebalance。首先對鏈路信息和 DB 運行狀態進行建模，將業務容量刻畫出來，進行水位模擬，能夠得出容量圖案。經過平臺的分析將圖案轉化成一個一個變動，下發到平臺造成變動鏈表。

SQL 調優。記錄每一條 SQL，給出SQL調優的建議。

壓測的資源預測和熔斷。若是預測到 RT 水位對於業務來講是超時的，就中止自動壓測。有助於下降線上的故障率。

OceanBase大促智能化模塊

感知。首先捕獲線上全部異常，異常是方方面面的，結合畫像進行 workload 建模，得出模型,預測。

決策。第一種方法是靠人的經驗，造成一個決策樹，對每一分支進行分析，往下尋找修復。第二種方法是機器學習，根據一些算法作輸入，經過演進和優化不斷得出最佳的決策方案。執行器。根據上層信息診斷得出須要執行的方案，好比須要調優，擴容或者其餘。對此作好冪等控制和免疫控制。由於有些執行不是無損的，能夠實時感知線上鏈路的變化，作成一個可監控可回覆的模塊來實現變動的免疫。

SQL自愈案例

SQL故障感知。下圖是支付寶網上銀行業務量的變化狀況。在報警格式下面有三個數字，kpi真實值是180ms,即限制監測到的真實狀況，預測值是6ms,即認爲應該是業務量長到6ms就能夠提供服務的，基線值285us。這三個數字得出以後發現到6ms以後每個月提供服務，因此不符合的預期。

故障識別。經過故障根因分析，給出三個規則。第一個是SQL id,就是指SQL有問題。第二個是IO出問題。第三個RPC出問題。經過分析得出機率比較高的問題，認爲規則1裏的SQL多是問題所在。

故障恢復的過程。根據SQL id給出診斷建議。診斷建議是全表掃描，提供可選擇的索引，這對於突發的SQL事件是十分有幫助的。

平臺智能化會提供索引綁定，更便捷地利用平臺智能化解決故障。在後期也會覆蓋更多能力。

5、將來發展規劃

資源。資源是大促的核心價值，要用最小的資源解決用戶最大的問題。首先經過統一調度，把DB，用戶服務器，各類機型，資源池所有打通，這樣技術可發揮的空間更大。第二，混合部署。統一部署以後會分池分佈，分類混布。最後，分時複用。混布和分時複用的效率體現很明顯，在不須要作大促處理的時候能夠節省資源開銷，2019年會對此作很大變化。

自治。智能化的最終目標就是自治，這也是如今的發展大趨勢。分爲 OceanBase 內核的自治和平臺化的自治。平臺化的自治分爲三塊,自愈，自調優和自駕駛。自愈就是自我修復，分爲硬件類和軟件類的故障修復。自調優就是Auto tuning，多是輸出運行的問題。自駕駛是擴縮容，租戶容量等平常的問題不須要人爲參與。

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