解開螞蟻金服自研金融級分散式資料庫OceanBase背後的技術祕密

  本文根據陳萌萌老師在2018年5月10日【第九屆中國資料庫技術大會】現場演講內容整理而成。

　　講師簡介：

▲螞蟻金服資深技術專家 陳萌萌

　　陳萌萌，螞蟻金服資深技術專家。目前在OceanBase團隊負責SQL相關方向的開發工作。2006年畢業於清華大學，2006年到2008年在歐洲核子研究中心(CERN)負責網格計算排程器的開發工作，2009年5月在美國威斯康辛大學麥迪遜分校獲得計算機碩士學位，先後在Oracle、華為美國研究所從事資料庫的開發和研究。

　　摘要：

　　作為自主研發的金融級分散式資料庫，多年來OceanBase穩定地支援了螞蟻金服雙十一峰值流量，並於2017年創造了25.6萬筆支付每秒的世界紀錄。作為新一代的關聯式資料庫，OceanBase在擴充套件性、高可用、高效能、低成本等方面解決了一系列世界性技術難題，為上層應用提供了“不停機縮擴容”、“彈性大促”、“多地多活”等多項核心能力。今天，我們將為你一一解開OceanBase背後的“技術祕密”。

　　分享大綱：

　　1、OceanBase簡介

　　2、核心技術優勢

　　3、下一代OceanBase

　　正文：

　　一、OceanBase簡介

　　在加入螞蟻金服後，我發現很多傳統資料庫或傳統架構難以解決的問題。OceanBase的定位是一個通用關係型資料庫，在螞蟻金服內部支撐了整個的核心交易系統。在架構層面，OceanBase與傳統資料庫最大的不同在於，它是一個分散式資料庫，在資料庫層面解決了業務的擴充套件性，並提供了高可用的資料庫服務。與此同時，OceanBase還提供了彈性部署能力，並通過使用廉價PC機極大地降低了系統的成本。

　　首先，讓我們簡要回顧OceanBase整個發展過程。2010年，該專案為解決淘寶收藏夾問題落地，此時還不是一個通用資料庫產品，功能上還只能通過定製的API進行訪問。2013年，OceanBase支援標準SQL介面。2014年，OceanBase第一次支援了螞蟻金服部分交易系統流量。2016年，第一個金融級雲資料庫版本正式釋出。2017年，螞蟻內部核心業務全部執行在OceanBase之上。

　　二、核心技術優勢

　　OceanBase的核心優勢可以總結為五點——線性擴充套件，高可用，一致性，低成本，易用性，以下逐一展開介紹。

　　1、線性擴充套件。傳統單機資料庫因受單機能力限制，所以擴充套件性有很大影響。OceanBase通過Paxos分散式協議、資料分割槽等機制對外提供了一致性保證，通過動態新增機器以獲得水平擴充套件能力。

　　2、高可用。傳統企業在解決高可用問題上更依賴高階硬體，成本增加的同時效能也會受損，因為它在軟體設計上並不考慮硬體失敗。在選擇普通PC機的前提下，螞蟻金服通過底層的分散式資料庫解決方案保證系統的高可用性。

　　3、一致性。對資料庫而言，在解決前兩大問題的基礎上還可保證一致性是困難的。OceanBase線上性擴充套件和高可用的基礎上，保證了資料庫ACID的一致性。

　　4、低成本。隨著雙十一交易量的超線性增長，資料庫效能最終體現在逐年提高的吞吐量上，OceanBase通過使用廉價的PC機，極大的降低了系統的硬體成本，並通過對單機效能的極致優化，在保證高效能的同時有效的降低了整個系統的執行成本，

　　易用性，OceanBase SQL模組支援智慧查詢優化與執行，與MySQL高度相容，以及Oracle增強功能，並提供多租戶混部能力，可以支援HTAP的業務使用場景。

　　要想解決一致性、高可用及可擴充套件問題，我們需要知道，分散式資料庫的高可用和一致性與傳統資料庫有哪些不同?

　　傳統資料庫通常是一主一備或一主多備模式，使用者必須在最大可用性與最大一致性之間做選擇，實際發生故障時很難切換。如果將資料同時落盤主庫和備庫，則犧牲了可用性;如果將資料非同步同步到備庫，很難保障故障發生時的資料一致性。

　　綜上，傳統資料庫很難給出有效的系統容災方案。

　　OceanBase底層基於分散式一致性協議Paxos，當有多份資料時，只要其中的多數派形成一致，就可以應答客戶。只要多數派存活，服務就不受影響，在保證一致性的情況下最大地兼顧系統可用性。

　　業務層面，OceanBase可以保證發生故障時，RTO小於30秒，RPO等於0。這意味著資料庫在任何故障下可在30秒內恢復服務，並且保證在恢復服務的過程中沒有任何的資料丟失。

　　OceanBase的一致性通過資料分割槽實現。在傳統資料庫中，資料分割槽(partitioning)是資料邏輯層的概念，可以把資料按照預定義邏輯方式分割槽。在OceanBbase中，該分割槽同時也是一致性或同步單元。下圖是一個三副本結構，其最小粒度可細化到資料分割槽，資料分割槽通過Paxos協議確保一致性，系統可在故障時自動選主，確保服務的自動恢復。

　　企業目前普遍使用的異地多活方案基本都是兩地三中心，這也是螞蟻金服內部早期使用的部署方案，所需的硬體條件是兩地三機房(三個Zone)。假設，深圳有一個兩機房，杭州有一個單機房，三個機房形成多數派投票，只要兩個副本存在，服務就可正常使用。此時，我可以容忍任何一個單機房或者單機故障。但是，如果深圳整個城市垮掉，多數派就不存在，系統就無法對上提供服務，但也不會發生資料丟失，因為所有同步方案都要保證多數派，如果兩個失敗，日誌就不會被同步或者提交。

　　另外，該方案的問題是缺乏二次容災能力，只允許單節點失敗，三副本是最基本的容災部署方式。

　　螞蟻金服對此提出的解決方案是三地五中心五副本架構。舉例說明，假設我在上海、杭州和深圳均有機房，且按照五副本方式部署，這裡的多數派為3個，這就意味著五個副本至少要同步3個。與兩地三中心的架構方式相比，新的架構增加了城市級容災能力，其中的兩個副本掛掉，依然符合多數派協議，同時具備抗二次故障的能力，。

　　該方案的不足之處是兩個城市之間的延時問題，每次事務提交都需要等待，延遲大概在幾毫秒左右。要想部署該方案，企業必須具備三地多機房的部署能力，這使得該方案並不適合所有使用者。

　　接下來是螞蟻金服彈性縮擴容問題解決方案講解。對螞蟻金服而言，彈性縮擴容方案最大的應用場景和挑戰就是每年的雙十一大促。對資料庫比較瞭解的都知道，當日常流量與系統峰值流量相差極大時，日常運營就需要儘可能降低成本，但高峰時又需要支撐極高吞吐量。對任何系統而言，都要考慮效能和成本之間的平衡。2016年，螞蟻金服開始嘗試通過彈性縮擴容的方式解決該問題。

　　在雙11之前，螞蟻金服使用彈性雲機房將系統能力臨時擴充。雙11以後，通過內部機制縮容。在資料庫層面，簡單來說可在不停服務的前提下，將資料庫資源資料彈出去並按照同樣方式收回。

　　具體操作步驟如下：

　　日常運營中，一個機房就足以裝下所有流量。當流量上升時，需要將其彈到雲機房，上圖中機房2、3、5、7為雲機房。此時，需要用到底層Paxos架構增減副本機制。

　　在要彈的機房中增加只讀副本，該副本不參與一致性投票，只負責資料同步。增加只讀副本後，資料會在系統內非同步複製。當資料逐漸接近，下一個操作就會執行。

　　上圖中部分副本的顏色發生改變，這意味著我們將之前的只讀副本升級為全功能副本，Paxos的投票成員個數也由三個變為五個。注意：從三副本升級五副本，主不會發生變化。

　　注意上圖中節點顏色變化。從五副本狀態到這，從投票節點變成不投票異部複製節點，內部會進行一次主改選。為了自動容災，選主隨時都可進行。通過改選，主被打散到機房2、3、4、5四個機房，流量也被拆成四份，相當於機房能力擴了四倍。選主完成後再對之前去掉的資料做成員變更，對之前的節點進行角色互換。雖然這部分操作較多，但選主和增加副本都是常規操作，不影響整個內部投票機制，並且在這個過程中，業務是無感知的。以上是底層的工作方式，上層需要通過路由把流量打到需要的機房，上下層互相配合最終完成彈性擴容。

　　以上是彈性擴容機制講解，接下來是儲存架構解讀。OceanBase儲存架構類似LSM tree，動態資料與靜態資料分離。與傳統資料庫原地修改方式不同，OceanBase所有動態修改(增刪改查)都在記憶體裡完成，靜態資料(不被修改的資料)存放在磁碟之上。我們在開始做OceanBase之時就意識到SSD會是主流儲存形態，該儲存方案可避免SSD隨機寫放大問題。由於動態資料與靜態資料分離，只在動態資料和靜態資料合併時需要寫盤，並且我們對寫盤進行了很多優化，保證資料塊按照一定粒度寫入，不會隨機修改某一頁面或某一地方。對SSD來說，整個生命週期沒有任何隨機寫操作。

　　同時，該架構支援靜態資料極致壓縮，允許對資料進行編碼操作，因為這部分資料平時不修改，所以可用字典編碼，整個儲存成本非常低。因為金融級資料對安全性非常敏感，因此，整個過程加入了多次資料強校驗環節。

　　接下來，我簡單介紹查詢優化部分工作。從1979年開始至今，傳統資料庫已經將查詢優化武裝到牙齒，螞蟻金服的查詢優化和傳統資料庫有什麼不一樣呢?

　　在這一點上，我們面臨三大挑戰。一是LSM tree儲存引擎架構決定了整個代價模型與傳統資料庫基於資料塊的代價模型有很大區別，由於每次讀取都要通過合併靜態資料和動態資料完成，因此我們在計算執行代價時需要同時考慮兩部分代價。

　　此外，由於很多執行操作基於剛修改過的資料，雖然不是嚴格意義上的In-Memory狀態，但是可認為是準記憶體資料狀態，對記憶體資料的訪問效能優化成為必須要解決的問題。我們在內部進行了一些嘗試，比如用編譯執行代替傳統的解釋執行，效能提高了至少十倍不止，至於在何時選擇何種解決方案就需要優化器參與決策。

　　第二大挑戰是分散式系統的優化場景比單機複雜得多，做分散式系統優化時需要考慮如何在極短時間內取得較好優化效果。此外，在分割槽計劃執行時，我們需要考慮針對分散式查詢的一些特定給的優化手段。

　　第三大挑戰是螞蟻內部應用場景複雜。螞蟻金服內部很多場景的資料變化非常劇烈，尤其是使用者進行高吞吐量突發性併發操作時，資料變化特徵非常明顯。我們在資料分片以後，有很多優化決策需要放在執行期來做，SQL的自適應優化與執行也是一個需要研究的課題。

　　分散式SQL執行引擎的設計也是使用者非常關心的話題，對於分散式資料庫，分散式執行引擎和查詢優化是效能的關鍵。我們對引擎部分的思考是希望支援OLTP和OLAP混合場景，面臨的問題是資料跨分割槽執行。對於分割槽內部的並行需求，我們利用單機多執行緒能力執行。為了將分散式執行(跨分割槽執行)與並行執行的需求相結合，我們的優化方案分為全域性優化和本地單機優化。在整個執行過程中，我們會同時考慮基於資料的水平並行和操作符間的流水線並行。與傳統資料庫的單級或兩級流水線並行操作相比，OceanBase支援多級流水線，把MPP系統的IO能力和CPU能力充分利用起來。我們認為，這是充分發揮整個分散式架構優勢的基本保證。

　　此外，OceanBase在1.0架構時就開始設計考慮雲服務的可能性，所以它是多租戶架構，這裡的租戶相當於傳統資料庫的例項。使用者可以通過叢集部署的多租戶將資源拆分給不同業務。比如，在支付場景下，如果使用者可以選擇A、B兩種支付渠道，A、B很難同時達到峰值流量。對於這種消長或者彌補流量的應用，可以考慮部署在同一叢集內。當然，實際考慮要素較多，此處不一一列舉。

　　同時，多租戶架構也可帶來資源隔離和資源利用率的提升，因為整個隔離並沒有按照物理上的虛機等方式做隔離，隔離的粒度可以更精細，overhead也更小。

　　隨著租戶數量增加，負載均衡是多租戶架構面臨的一大難題。在分散式系統裡，負載均衡屬於NP問題，沒有絕對優雅的解決方案。考慮到該架構特性，我們的負載均衡方案是，對於小租戶的請求，儘量在一臺機器上滿足，這樣可以避免分散式事務;對於有資料分片的租戶，我們會將其打散到多個機器，充分利用機器能力。下圖為擴容前後負載均衡的變化情況以及大量小租戶資源隔離效果圖：

　　下一代OceanBase

　　預計在今年9月份，OceanBase將會發布2.0版本。新版本主要強調通用性，在傳統能力上，提供很多傳統資料庫的功能，比如全域性快照、全域性索引，資料編碼優化、自適應執行計劃、流量回放、相容性等。從商用角度講，OceanBase 2.0版本也會是更加成熟的商用版本。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2155068/，如需轉載，請註明出處，否則將追究法律責任。