首發 | OceanBase 2.0 重磅發佈，全面下降金融業務向分佈式架構轉型的技術風險

OB君：9月21日下午，在雲棲大會ATEC數字金融架構轉型分論壇中，螞蟻金服OceanBase團隊的資深技術專家蔣志勇正式宣佈OceanBase 2.0重磅發佈，並深刻解讀了OceanBase 2.0的產品新特性和重大技術突破點。

OceanBase是一款徹底自主研發的金融級分佈式關係數據庫，超過100萬行的核心代碼都由OceanBase團隊的同窗一行行敲出來。

從2010年立項到今天，過了8年；在最近4年多時間裏，一直服務於金融核心業務。2014年，OceanBase開啓了支付寶核心業務去Oracle的進程，在當年的「雙十一」，支撐了10%的交易流量；最終在2017年，成功完成支付寶交易、支付、帳務、會員等所有核心業務的去Oracle的工做。這在中國乃至全球都是一個標誌性的事件。

對比一下美國的狀況，前段時間有報道稱亞馬遜準備在2020年完全去除對Oracle數據庫的依賴，馬上引來了Oracle創始人的反擊，他表示亞馬遜已經嘗試過不少次，但從未成功，足以見得去Oracle這件事對於企業而言的難度之大。

一樣在2017年，OceanBase和螞蟻金融科技的其餘產品一塊兒幫助南京銀行創建了互聯網金融核心系統。從去年開始截止到今天，OceanBase已經在6家外部金融機構上線，包括商業銀行和保險機構。全球前三名的支付平臺，兩家的核心繫統都在使用OceanBase數據庫。

爲了知足業務快速發展以及持續可用的要求，系統架構從集中式轉向分佈式是大勢所趨。在數據庫層面，要相應地從單機數據庫轉向分佈式數據庫。

今天，咱們發佈OceanBase 2.0版本，這是OceanBase數據庫自身發展的里程碑，也是咱們參與金融行業向分佈式架構轉型的關鍵一步，用數據庫技術創新爲業務架構轉型奠基基礎，解除行業發展的後顧之憂。

在架構轉型過程當中，技術決策者每每會碰到三大挑戰：

第一大挑戰：技術風險

第一個是技術風險，傳統單機數據庫系統通過幾十年的發展，運行在可靠的專用硬件和存儲上，在金融行業獲得充分鍛鍊，總體穩定。分佈式數據庫系統運行在普通商業硬件上，採用廉價存儲，運行環境和傳統方式有很大差別，保證系統可用性和可靠性的手段也大不相同；同時在某些基本行爲方面和傳統單機數據庫也有差別。好比要獲取一個系統一致性快照，對單機數據庫是一件很輕鬆的事情，但在分佈式系統中，卻沒那麼容易。若是不能提供一致性快照，業務系統就被迫要作相應的改造和調整，調整就會帶來風險。能夠說：對於一些基本特性，分佈式數據庫系統相對於傳統數據庫的每個行爲上的差別都增長了架構轉型的不肯定性，頗有可能就是在轉型的道路上埋了一個雷。

第二大挑戰：遷移實施成本

傳統數據庫是功能的集大成者，分佈式數據庫因爲發展時間較短以及分佈式架構自身的複雜性，在功能上比傳統數據庫有所欠缺。若是缺乏的正是業務系統須要的功能，每每就要經過修改業務系統來解決。除了系統改形成本，還有運維成本，人員知識結構更新帶來的成本，等等。

第三大挑戰：新產品的質量和服務

最後一點是新產品的質量和服務可否知足金融業務的要求。數據庫產品和其餘產品的重要差別在於它關乎企業的核心數據資產。數據庫新產品的質量不能僅僅依靠測試報告來保證，而是要看有沒有通過實際業務的長期鍛鍊。對於應用過程當中出現的任何問題，技術研發和服務團隊有沒有能力限期解決。

上述的三個問題，是技術決策者須要思考和解決的。

OceanBase 2.0的發佈，在必定程度上就是爲了解決上面的三個問題，減輕技術決策者的決策風險。今天的報告分紅以下六個部分，分別介紹OceanBase2.0在減小分佈式架構對業務的影響、提升數據可用性、加強運維能力、提高性價比和產品兼容性方面的進展，最後還會談一談2.0版本在今年「雙十一」大促中將要承擔的任務。

業務透明的分佈式系統

對分佈式數據庫而言，若是對業務能表現成一個具有動態伸縮能力、功能完備的高可用單機數據庫，那基本上就達到了向業務屏蔽分佈式架構複雜性的目標。把分佈式架構實現的複雜性留給了本身，把便利性提供給了業務。爲了這個目標，OceanBase 2.0版本實現了全局一致性快照，支持了全局索引，豐富了負載均衡策略。

1. OceanBase的總體架構

先來看一下OceanBase的架構，從1.0版本就確立下來的對等節點無共享存儲分佈式架構。集羣中的每個節點都是對等的，包含完備的SQL、事務、存儲引擎，負責管理一部分分區，並響應客戶端的請求。

在全部的節點中，有部分節點承擔了集羣全局性的管理功能，圖例中的Root Service節點，略微有點特殊，可是這個管理能力是其餘節點都具有的，在必要的時候能夠隨時接管。

爲了高可用，數據一般有多個副本，分佈在不一樣的可用區，圖例中部署有三個可用區，單節點故障、單可用區故障都不會影響系統和數據的可用性。在9月20日ATEC主論壇中演示的「三地五中心」高可用架構，在發生城市級故障的時候數據不丟失，26秒恢復業務，用的數據庫就是OceanBase。OceanBase也是雲數據庫，單個集羣服務多個租戶，租戶之間數據和資源隔離。

2. 全局一致性快照

在沒有實現全局一致性快照以前，分佈式數據庫在功能上是有比較大的欠缺的。有兩個典型問題：一個是沒法實現跨節點的一致性讀，另外一個是沒法保證因果序。

沒法實現跨節點的一致性讀，對於應用系統設計和開發人員是頗有挑戰的，他們得保證在一條SQL語句中訪問的多個表、多個分區都在同一個節點上，不然這個查詢就會出錯。

沒法保證因果序的一個表現是：用戶在兩個事務中分別修改了位於兩個節點上的兩張表，先修改了源表，再改了目的表。但在另外的一個觀察者看來：後修改的表已經在查詢中反映出來了，但源表尚未變。這對於依賴操做順序的業務系統，簡直是個災難。

OceanBase 2.0版本實現的全局一致性快照，從根本上解決了這些問題。相對於Google Truetime基於原子鐘的硬件實現，OceanBase的全局時間戳（GTS）服務是純軟件實現的。不依賴特定的硬件設備，也不對客戶方的部署環境提額外的要求，使得OceanBase可以服務更普遍的專有云客戶。

全局時間戳（GTS）服務是系統的基礎服務，該服務的性能和可用性對系統有很大的影響。OceanBase 2.0的單個全局時間戳服務1秒鐘內可以響應2百萬次以上的時間戳獲取請求，知足單租戶百萬級TPS的要求。在系統滿負荷運行的狀況下，對性能的影響不超過5%。時間戳服務的高可用機制和數據分區高可用機制相同，後者在過去幾年中經歷了支付寶生產系統嚴苛的檢驗，很是穩定。

2.0版本的全局時間戳服務缺省打開，跨節點讀寫、因果序的行爲和單機數據庫徹底一致。對於數據都集中在一臺機器上的小租戶，或者對性能有極致要求的租戶，能夠選擇關閉本身的全局時間戳服務。

3. 全局索引

全局索引是單機數據庫的經常使用功能，在分佈式數據庫中比較難實現。對於分區表來講，全局索引的價值在於爲不帶分區鍵條件的查詢提供一種性能提高手段。在沒有全局索引的時候，不帶分區鍵條件的查詢性能是比較差的，要在每個分區上作一遍這個查詢，而大部分分區上根本沒有知足條件的記錄。

咱們看到，有些業務不能接受這麼長的查詢響應時間，就會建立另一張表來模擬全局索引的功能，這個額外建立的表的維護就會帶來不少問題，數據一致性、以及在何種狀況下使用這個表都須要應用系統去管理。

全局索引功能將業務從這些問題中解脫出來。在全局索引的建立和使用上，OceanBase都基於代價作選擇，在建立的時候，能夠基於基本表，也能夠基於另一個索引。大表的索引建立一般耗時較長，對於大規模的分佈式系統，設備故障也並很多見，爲了提升建立索引成功率，在發生錯誤的時候採用子任務級別的重試。

對於查詢優化器來講，什麼時候採用哪個全局索引也是基於代價計算的，目前索引回表查詢是經過在計劃上生成基礎表和全局索引表的鏈接操做來實現的，代價模型也和通常查詢相同。對有全局索引表的DML和查詢操做很容易產生分佈式查詢和分佈式事務，爲了提高性能，在實現上作了不少細節優化，好比對於分佈式查詢，將任務的粒度從以前的分區級提高到節點級，以便減小RPC的次數。

4. 負載均衡

在負載均衡方面，2.0版本豐富了均衡策略。租戶內的負載均衡讓該租戶上的工做負載能比較平均地分配在租戶的多個節點上，對於數據裝載和分析型的查詢，能夠有效地減小響應時間。此外，還能夠設置租戶間的親和關係，實現將負載高峯出現時段相同的租戶分佈在不一樣節點上，峯值時段不一樣的租戶分佈在同一個節點上，充分地利用系統資源。除了提供給用戶可配置的手段，負載均衡還結合CPU、Mem、存儲等資源的使用狀況，在負載差別超過閾值的時候，自動平衡節點間的負載，簡化運維操做。

數據持續可用

在9月20日下午螞蟻金服副CTO胡喜的主題演講中，演示了OceanBase三地五中心城市級故障無損容災方案，樹立了金融核心業務高可用新標杆。

這一場三地五中心方案的現場演示是咱們1.4版本支持的特性。在提高數據可用性方面，2.0版本也有了顯著改進，索引實時生效、閃回查詢、在線分區分裂，這三個新特性，每個都解決了業務使用中的痛點。

1. 索引實時生效

瞭解OceanBase以前版本的同窗都知道，索引生效和每日合併是強綁定的，普通索引的生效要通過一次每日合併，惟一索引要通過兩次。有的時候，索引建立失敗了，業務還不知道，形成了很大的困擾。

在2.0版本中，索引建立和每日合併解耦，索引基於數據的一個全局快照建立，再合併後續的變動，建立成功便可使用。若是出現錯誤，也能及時給用戶反饋，提高了用戶體驗。經過先在一個數據副本上建立索引，成功之後再經過複製的方式生成其餘的副本，避免同時在多個副本上建立索引形成的系統資源浪費。支持建立全局惟一索引，進行全局惟一性檢查；在數據一致性校驗方面，和以前的版本同樣，會檢查索引和表中的相同列的一致性。

2. 閃回查詢

閃回查詢功能，能夠指定查詢某個歷史時間點的數據，對減小用戶誤操做形成的影響頗有幫助。假如用戶不當心刪除了一些有價值的數據，能夠經過指定刪除以前的時間點來查詢以前的數據。

在OceanBase的實現中，內存中的修改記錄本來就是多版本的。爲了支持閃回查詢，要求轉儲到外存中的數據也要保留多個版本。至於保留多長時間範圍內的版本，用戶能夠根據本身的須要進行配置，每個表均可以按需單獨配置。爲了減小多版本轉儲對存儲的壓力，存儲層也將數據編碼和通用壓縮應用在轉儲上，有效地減小存儲消耗。同時，在執行查詢語句時，若是指定了快照版本號，查詢也能夠在從副本執行，分擔主副本節點的壓力。

3. 在線分區分裂

另一個提升數據可用性的功能是在線分區分裂，該功能對系統擴容頗有幫助。在業務早期設計表的時候，對將來的增量頗有可能預估不足，因此業務發展起來之後，就須要把單個分區再拆分，分紅多個分區，再用多臺服務器來服務這些分裂出來的分區，達到系統擴容的目的。

若是須要拆表的業務不能停服務，拆分操做就須要在線完成。在2.0版本中，分區分裂分紅兩個步驟，邏輯拆分和物理拆分，邏輯拆分是在表模式上把單個分區變成多個分區，完成表的元信息更新。物理拆分是把原先單個分區中的數據移動到新生成的分區中去。邏輯拆分在用戶的DDL語句返回的時候就完成了，物理拆分是後臺運行的。在物理拆分沒有最終完成前，仍然會用到以前分區的數據。

在分區分裂的過程當中，也控制了存儲空間的使用，舊分區某一個宏塊的數據所有被轉移到新分區了，該宏塊空間就被回收了。

在分佈式系統中，分區大小對負載均衡、副本遷移、複製都有影響，把分區控制在較小的規格是有價值的。在線下OceanBase 2.0測試集羣中，單個節點可以服務百萬個分區；線上生產系統單節點服務十萬個分區。知足分區拆分以及雲環境下對單節點分區服務能力的要求。

可運維性加強

分佈式數據庫相對於單機數據庫，不管是部署仍是運維都要複雜一些，因此提升系統的可運維性也是2.0版本的一個重要目標。今天主要講三個方面：DB Replay功能、在線升級以及新運維管控平臺OCP2.0。

1. DB Replay

DB Replay是一個頗有用的功能，一方面能夠下降系統升級的風險，另外一方面也能夠用來作壓測，保障大促。DB Replay主要分紅三個部分：線上流量抓取，要求不能影響線上系統的服務能力；第二部分是流量分析，由於真實系統的流量很是大，抓取的數據量也很大，對分析的性能要求高，同時爲了更接近抓取時的Session併發狀況，在併發語句相關性分析上，粒度是行級而不是同類產品一般採用的表級；第三個部分是流量回放，保持和線上系統一樣的會話之間的關係，而且能夠經過調整語句之間的時間間隔來放大或者縮小對系統的壓力，達到壓測的目的。

2. 在線升級

做爲長期支持核心業務的數據庫系統，對升級的要求就是平滑、可灰度、可回滾。版本之間的數據格式是兼容的，新版本的程序能理解老版本的數據。同時經過可用區輪轉升級，能夠作到在線升級；在升級的過程當中能夠灰度切流驗證，在出現異常的狀況下能夠回滾，不會對系統形成嚴重影響。

3. 新版雲管控平臺

數據庫運維管理一直就不是一件容易的事情，對於分佈式數據庫更是如此。「工欲善其事、必先利其器」。OCP（Open Cloud Platform）2.0就是一款專門用來管理OceanBase數據庫集羣的管控平臺，經過OCP平臺，能夠一鍵安裝、部署、升級OceanBase集羣，監控集羣的運行狀態，建立和維護運維任務。

相對於1.0版本，2.0版本進行了架構上的改造，提高了服務的可用性，去除了對HBase、JStorm等外部組件的依賴，減小了最小化部署對服務器資源的消耗，從原先的3臺物理服務器到2個Docker，很是適合對成本敏感的專有云客戶。同時提供SDK供第三方定製管控平臺。在服務能力方面，OCP集羣可以動態擴展，每秒可以響應百萬次的http請求，充分知足運維須要。

性價比提高

針對性能，咱們主要作了兩方面的工做：提交協議的優化和工程實現層面的優化。提交協議優化指的是對分佈式事務二階段提交協議的優化，在這一方面，目前在申請相關的專利，這裏暫時不展開。在工程實現優化方面，咱們作了大量細緻的工做，包括內存分配、臨界區、數據類型轉換等。在下降存儲成本方面，經過對靜態數據進行編碼，有效地減小了存儲使用。經過這一系列的改進，在OLTP場景的實際應用中，2.0版本相對於1.4版本，性能提高了50%以上，存儲降低30%。

兼容性提高

最後說說2.0版本的兼容性，咱們花很大的力氣作兼容性，就是要減小數據庫遷移形成的業務系統改造，下降遷移成本，同時使得業務數據庫設計人員、開發人員、數據庫管理員原先積累的知識和經驗可以在新系統中複用。

1. 兩種兼容模式

在1.x版本中，咱們主要作的是MySQL兼容。2.0版本支持兩種兼容模式：MySQL和Oracle，目前Oracle兼容還比較有限，不久以後會有一個顯著的提高。同一個集羣中的多個租戶，能夠採用不一樣的兼容模式，在租戶建立的時候指定，後續不能更改。對兼容性的要求，不只僅是語法層面的兼容，還有語義方面、異常狀況下的行爲、併發行爲、甚至於性能，均可以看做兼容性表現的一部分。

試想一下，一樣的語句，新系統的響應時間是原系統的10倍，哪怕是語法兼容作得再好，也根本沒法知足業務要求，又有什麼用呢？

2. 存儲過程功能

在功能方面，2.0版本實現了一個標誌性新特性—存儲過程。咱們實現存儲過程，有兩個方面的目的：一個是兼容性，咱們瞭解到，在傳統行業中仍是有很多系統是基於存儲過程實現的。經過支持存儲過程能夠顯著下降這部分系統的遷移成本。另一個是高可用，經過使用存儲過程，能夠顯著減小業務系統和數據庫服務器之間的交互，若是業務流程的幾十條、幾百條SQL語句經過一個存儲過程來實現，即使出現跨城的業務對數據庫的調用，也不會對用戶體驗有明顯的影響，系統的容災將會更容易實現，穩定性也會更高。在爲數很少的原生分佈式數據庫產品中，OceanBase是第一款支持存儲過程功能的。

存儲過程也支持MySQL、Oracle兩種模式。若是業務不想讓數據庫來管理代碼，也能夠採用匿名塊的使用方式，既有開發靈活性，又能得到存儲過程帶來的好處。存儲過程採用LLVM編譯執行，效率比解釋執行高；支持基本調試功能，方便對大規模存儲過程的開發和調試。

OceanBase 2.0的第一個「雙十一」

做爲阿里系的產品，不通過「雙十一」的考驗是不完整的。今年是天貓的第十個「雙十一」，也是OceanBase 2.0經歷的第一個「雙十一」。

雖然剛剛出道，也要堪當大任。2.0版本將要承擔一大部分支付寶的核心業務，同時，藉助於2.0的在線分區分裂技術和全局索引功能，業務核心表要實現拆分，從非分區表拆成若干個分區表。

今年大促的峯值流量預計會大幅增長，但數據庫服務器的成本不能增長，要靠提高數據庫性能來幫助實現「零新增成本大促」這個目標。

聽到這裏，你們應該明白了，2.0版本所作的技術創新和產品改進，都來自於業務的真實需求，也會很快接受業務的檢驗。這是推進OceanBase數據庫不斷向前發展的原動力，也是OceanBase區別與市場同類產品的最大不一樣。咱們輸出到外部市場的產品都是通過內部業務嚴格檢驗過的，每一年的「雙十一」大促都是對OceanBase數據庫獨一無二的壓力測試。

最後，以OceanBase 2.0相關的幾個數字來做爲結尾：

「1」

第一個支持存儲過程的原生分佈式數據庫系統

「30｜50」

存儲減小30%，性能提高50%

「100萬」

單臺服務器的分區服務能力達到100萬個

「200萬」

單個租戶GTS服務能力達到每秒200萬次

OceanBase 2.0技術交流羣

想了解更多 OceanBase 2.0 特性？

想與螞蟻金服OceanBase的一線技術專家深刻交流？

掃描下方二維碼聯繫螞蟻金服加羣小助手，快速加入OceanBase技術交流羣！