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

演講嘉賓簡介:田啓傑(花名:天街)

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

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

本次的分享主要圍繞以下五個方面:

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

一、2018 OceanBase大促概述

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

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

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

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

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

壓測。如果大促的流量要翻五六十倍,那麼爲了保證增加新機器時不出問題,並且成本可控,就需要儘可能模擬真實業務的工作壓力,把真實情況下的熱點對數據庫的衝擊在壓測環境下模擬出來。

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

如果能夠合理應對以上6點挑戰,那麼就能夠在技術角度完美地支持和應對雙11大促。

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

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個機房來進行服務,所以它在可預見的範圍內是不會成爲瓶頸的。四小時建站,可以在四小時之內在任意一個站點把支付寶的任意的服務都搬到上面去,包括數據,代理數據也可以遷出去。

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

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個機房來進行服務,所以它在可預見的範圍內是不會成爲瓶頸的。四小時建站,可以在四小時之內在任意一個站點把支付寶的任意的服務都搬到上面去,包括數據,代理數據也可以遷出去。
螞蟻金服天街:螞蟻雙11大促OceanBase核心技術全解析

二、百萬支付&OceanBase2.0

百萬支付目標

下圖展示每年雙11峯值的能力和成交的筆數,十年來雙11峯值的攀升基本上是垂直上漲的曲線。在未來,峯值能力怎麼能夠不成爲支付的瓶頸?比如目前只能支撐50萬人同時支付,那該如何打破這個瓶頸?未來可能需要有100萬人在每秒一起進行工作。螞蟻提出了三年戰鬥百萬支付的目標,在高峯期,一秒鐘進行100萬的支付,同時一天可以支撐1億訂單。
螞蟻金服天街:螞蟻雙11大促OceanBase核心技術全解析

百萬支付瓶頸

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

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

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

OceanBase2.0理念

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

OceanBase2.0架構

那麼OceanBase2.0架構下的路由是怎麼工作的?一個服務器過來發給SQL,SQL傳給中間件,中間件提供路由功能,它把分庫分區表的規則做好,比如表級別的規則,DB級別的規則,彈性的規則以及分區的規則。中間件把分片的信息發送到OBClient, OBClient會製造一個生成列partition_id,發送給OBerver,由做一個分區裁剪。分區裁剪會精確地找到分片所在的DB上的應用服務器在哪裏。生成列與業務方綁定在一起,從業務日常表的列中選取兩位最適合的做分片,孕育出來生成列的規則應用在表級別,全棧的表都採用這樣的規則。另外,分區規則的維護是一個固化的規則,OceanBase通過約束能力(constraint)提供分區裁剪能力,這時不要求中間件有分區裁剪能力,只要把約束定義好,把OceanBase調到最佳就可以了。
螞蟻金服天街:螞蟻雙11大促OceanBase核心技術全解析

百萬戰略基石

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

三、容器化

爲什麼要進行容器化?

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

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

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

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

容器化三個核心點

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

規格統一。規格統一最重要的是分配,如UID,業務的分配。在進業務端入口時分成資源進口分流,不會稱爲訪問的熱點。同時做業務改造,讀請求較高的時候加讀庫可以降低壓力。通過資源規格歸一之後,定義出的無數規格可以滿足螞蟻所有資源的訴求。

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

多維調度。多維調度的範圍比較大,這裏的資源是廣義的資源,從業務入口一直到真實落到DB的過程中以不同的資源維度進行調度。
螞蟻金服天街:螞蟻雙11大促OceanBase核心技術全解析

OceanBase大促容器化架構

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

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

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

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

四、平臺智能化

爲什麼要做平臺智能化?

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

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

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

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

OceanBase 大促智能化實踐

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

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

壓測的資源預測和熔斷。如果預測到 RT 水位對於業務來說是超時的,就停止自動壓測。有助於降低線上的故障率。

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

OceanBase大促智能化模塊

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

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

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

SQL自愈案例

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

故障識別。通過故障根因分析,給出三個規則。第一個是SQL id,就是指SQL有問題。第二個是IO出問題。第三個RPC出問題。通過分析得出概率比較高的問題,認爲規則1裏的SQL可能是問題所在。
螞蟻金服天街:螞蟻雙11大促OceanBase核心技術全解析

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

故障恢復的過程。根據SQL id給出診斷建議。診斷建議是全表掃描,提供可選擇的索引,這對於突發的SQL事件是十分有幫助的。
螞蟻金服天街:螞蟻雙11大促OceanBase核心技術全解析

平臺智能化會提供索引綁定,更便捷地利用平臺智能化解決故障。在後期也會覆蓋更多能力。
螞蟻金服天街:螞蟻雙11大促OceanBase核心技術全解析

五、未來發展規劃

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

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

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章