各位關(guān)心OceanBase數(shù)據(jù)庫(kù)的同學(xué)，大家好！我是OceanBase團(tuán)隊(duì)的蔣志勇。借DBAplus社群直播平臺(tái)，和大家聊一聊近八年來(lái)OceanBase的發(fā)展以及關(guān)鍵特性。

OceanBase數(shù)據(jù)庫(kù)是阿里巴巴和螞蟻金服完全自主研發(fā)的金融級(jí)分布式關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)，和基于開源數(shù)據(jù)庫(kù)產(chǎn)品進(jìn)行改造的解決方案不同的是：OceanBase內(nèi)核100多萬(wàn)行代碼都是我們的同學(xué)一行行寫出來(lái)的，所以我們對(duì)其有完全的掌控力，這一點(diǎn)對(duì)OceanBase的持續(xù)發(fā)展以及獲得更廣泛的應(yīng)用有著十分重要的意義。

從2010年立項(xiàng)開始算起的八年時(shí)間里，OceanBase版本號(hào)也從0.1版本升到即將推出的2.0版本。從最初的Key－Value存儲(chǔ)系統(tǒng)發(fā)展到現(xiàn)在功能齊備的關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)。整個(gè)過(guò)程中，我們始終不變的初心就是服務(wù)業(yè)務(wù)，解決業(yè)務(wù)實(shí)際問(wèn)題，不斷增強(qiáng)產(chǎn)品能力，然后更好地服務(wù)業(yè)務(wù)。

遵循“解決問(wèn)題→發(fā)展產(chǎn)品→解決更大的問(wèn)題→鍛煉出更好的產(chǎn)品”這個(gè)循環(huán)：

• OceanBase從解決收藏夾的海量數(shù)據(jù)存儲(chǔ)問(wèn)題入手，有了一個(gè)小團(tuán)隊(duì)并活了下來(lái)；

• 為了解決高可用的問(wèn)題，采用三集群部署方式；

• 為了降低業(yè)務(wù)遷移成本及支持分析型應(yīng)用，增加了SQL功能；

• 到目前的全對(duì)等架構(gòu)、三地五中心城市級(jí)自動(dòng)容災(zāi)（可參考：城市級(jí)故障自動(dòng)無(wú)損容災(zāi)的“新常態(tài)”方案）、支持主流關(guān)系數(shù)據(jù)庫(kù)功能使得業(yè)務(wù)零修改遷移，最終使得支付寶核心業(yè)務(wù)能夠運(yùn)行在OceanBase上。

OceanBase從立項(xiàng)開始，目標(biāo)之一就是在不可靠的硬件上提供可靠的關(guān)系數(shù)據(jù)庫(kù)服務(wù)。我們誕生于高速發(fā)展的互聯(lián)網(wǎng)行業(yè)，高端存儲(chǔ)和專用服務(wù)器的訂貨周期太長(zhǎng)，供應(yīng)也很受限。能方便獲取的硬件只有普通PC服務(wù)器，所以O(shè)ceanBase只能依靠分布式架構(gòu)，用軟件的手段，在不可靠的硬件環(huán)境中實(shí)現(xiàn)金融級(jí)可靠性及數(shù)據(jù)一致性。

經(jīng)過(guò)八年多的實(shí)踐，從淘寶的收藏夾業(yè)務(wù)走到今天支撐支付寶所有核心業(yè)務(wù)，并且在每年的“雙十一”持續(xù)地創(chuàng)造交易數(shù)據(jù)庫(kù)峰值處理能力的世界紀(jì)錄。在去年“雙十一”大促中支撐了支付寶全部的核心業(yè)務(wù)（含交易、支付、會(huì)員、賬務(wù)），峰值處理請(qǐng)求數(shù)達(dá)到4200萬(wàn)次每秒。

從特性上說(shuō)，OceanBase具備線性擴(kuò)展、高可用、高性能、低成本，以及和主流關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品高度兼容等特點(diǎn)。

從1.0版本開始，OceanBase架構(gòu)就進(jìn)化成為全對(duì)等節(jié)點(diǎn)，無(wú)共享存儲(chǔ)方式。這個(gè)架構(gòu)特點(diǎn)消除了單點(diǎn)，每個(gè)節(jié)點(diǎn)都具有完備處理能力，能夠管理本節(jié)點(diǎn)上的數(shù)據(jù)。在節(jié)點(diǎn)角色上，有幾個(gè)節(jié)點(diǎn)（root service）負(fù)責(zé)管理集群拓?fù)浣Y(jié)構(gòu)等全局信息，相對(duì)特殊一點(diǎn)，但每個(gè)節(jié)點(diǎn)都具備承擔(dān)這個(gè)角色的能力，如果當(dāng)前承擔(dān)該角色的節(jié)點(diǎn)發(fā)生故障，集群會(huì)自動(dòng)選舉出新的節(jié)點(diǎn)承擔(dān)這個(gè)角色。

此外，為了高可用，集群節(jié)點(diǎn)分布在多個(gè)不同的可用區(qū)，可以是同城不同機(jī)房，或者異地多個(gè)機(jī)房；一份數(shù)據(jù)在多個(gè)可用區(qū)里有副本，副本個(gè)數(shù)通常是奇數(shù)個(gè)。在螞蟻金服的實(shí)踐中，通常是3個(gè)或者5個(gè)，少數(shù)副本故障不影響系統(tǒng)可用性。

百萬(wàn)級(jí)QPS前端代理

在OceanBase集群之上，我們提供一個(gè)反向代理OBProxy。看到這個(gè)，大家可能會(huì)聯(lián)想到基于中間件構(gòu)建的MySQL集群，但這兩者是有本質(zhì)區(qū)別的：簡(jiǎn)單地說(shuō)，沒有OBProxy，OceanBase集群一樣能夠工作，具備完整處理能力。

那我們?yōu)槭裁匆蠴BProxy呢？主要出于兩方面的考慮：

• 一個(gè)是性能，通過(guò)OBProxy的路由功能，可以比較準(zhǔn)確地將語(yǔ)句路由到合適的節(jié)點(diǎn)處理，減少集群內(nèi)部轉(zhuǎn)發(fā)；

• 另外一個(gè)是容錯(cuò)能力，在網(wǎng)絡(luò)發(fā)生閃斷情況下，OBProxy可以重建連接，讓業(yè)務(wù)無(wú)感知。

分布式架構(gòu)對(duì)業(yè)務(wù)透明

對(duì)業(yè)務(wù)來(lái)說(shuō)，OceanBase分布式架構(gòu)能做到的最好狀態(tài)是什么呢？我認(rèn)為是對(duì)業(yè)務(wù)透明。通過(guò)分布式架構(gòu)，我們做到高可用、做到可擴(kuò)展，但是對(duì)業(yè)務(wù)系統(tǒng)，要做到透明，表現(xiàn)為一個(gè)單節(jié)點(diǎn)數(shù)據(jù)庫(kù)，體現(xiàn)在如下幾點(diǎn)：

• 業(yè)務(wù)無(wú)需關(guān)心數(shù)據(jù)庫(kù)對(duì)象的物理位置。業(yè)務(wù)連上OBProxy或者任何一個(gè)OB節(jié)點(diǎn)，就能看到完整的視圖，能訪問(wèn)所有它有權(quán)限訪問(wèn)的數(shù)據(jù)。

• 集群SQL功能集等同于單節(jié)點(diǎn)SQL功能集。采用標(biāo)準(zhǔn)SQL語(yǔ)法，并且不因?yàn)閿?shù)據(jù)分布影響SQL功能。當(dāng)前版本大部分功能都做到了數(shù)據(jù)位置無(wú)關(guān)，但還有少數(shù)功能受位置影響，比如我們不支持在一條DML語(yǔ)句中修改多個(gè)節(jié)點(diǎn)的數(shù)據(jù)。在即將發(fā)布的2.0版本中，這些問(wèn)題都會(huì)得到解決。

• 完整支持事務(wù)ACID特性，統(tǒng)一事務(wù)操作接口。業(yè)務(wù)無(wú)需區(qū)分分布式事務(wù)和單機(jī)事務(wù)，數(shù)據(jù)庫(kù)內(nèi)部會(huì)對(duì)不同的場(chǎng)景進(jìn)行區(qū)分并做相應(yīng)的優(yōu)化。

• 自動(dòng)處理分布式環(huán)境故障、做到業(yè)務(wù)無(wú)感知。通過(guò)OBServer 和OBProxy的重試機(jī)制，可以做到大多數(shù)環(huán)境故障對(duì)業(yè)務(wù)透明，但相對(duì)于之前建立在高可靠硬件上的單機(jī)系統(tǒng)，還有一些差異，個(gè)別場(chǎng)景異常需要業(yè)務(wù)處理。

在滿足業(yè)務(wù)高速發(fā)展的過(guò)程中，OceanBase數(shù)據(jù)庫(kù)要解決的首要問(wèn)題就是擴(kuò)展性問(wèn)題。

通過(guò)全對(duì)等節(jié)點(diǎn)架構(gòu)，我們消除了之前版本單點(diǎn)寫入瓶頸。業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)的要求是不停服務(wù)，永遠(yuǎn)在線，為此所有的操作都要是在線的。傳統(tǒng)的垂直擴(kuò)展的方式不行了，只能采用水平擴(kuò)容的方式。這從方法上看也很直觀，怎么做呢？分三步走：

在集群中增加節(jié)點(diǎn)→讓新節(jié)點(diǎn)具備服務(wù)能力→將一部分負(fù)載分發(fā)到新節(jié)點(diǎn)上

看起來(lái)，似乎和將大象裝進(jìn)冰箱一樣，步驟明確。但每一步都不是那么好做的。

因?yàn)镺ceanBase是無(wú)共享存儲(chǔ)的，要想新增加的節(jié)點(diǎn)能夠分擔(dān)負(fù)載，新節(jié)點(diǎn)上先要有數(shù)據(jù)。最難的是此過(guò)程中既要保證數(shù)據(jù)一致性，又要不影響業(yè)務(wù)。無(wú)論是機(jī)房擴(kuò)容（機(jī)房?jī)?nèi)新增機(jī)器）還是擴(kuò)展到新機(jī)房（很有可能是異地或公有云場(chǎng)景），我們都必須做到在線。在OceanBase的實(shí)現(xiàn)中，主要依賴如下幾點(diǎn)：

• 多副本機(jī)制。多副本不僅是高可用的基礎(chǔ)，也是在線擴(kuò)容的基礎(chǔ)。從本質(zhì)上來(lái)看，擴(kuò)容無(wú)外乎兩種：一種是將新數(shù)據(jù)寫入到新節(jié)點(diǎn)，后續(xù)對(duì)該部分?jǐn)?shù)據(jù)的讀寫也在新節(jié)點(diǎn)；另一種是將現(xiàn)節(jié)點(diǎn)上的部分?jǐn)?shù)據(jù)移動(dòng)到新節(jié)點(diǎn)并在新節(jié)點(diǎn)提供服務(wù)。

  第一種情況容易處理；第二種情況就需要利用多副本機(jī)制，簡(jiǎn)單地理解就是把其中的一個(gè)副本從原節(jié)點(diǎn)遷移到新節(jié)點(diǎn)，說(shuō)起來(lái)簡(jiǎn)單，做起來(lái)有很多的細(xì)節(jié)要考慮，比如在異地增加一個(gè)副本，怎么樣做到既能高效地遷移數(shù)據(jù)同時(shí)又不影響現(xiàn)有服務(wù)。

  可參考：多類型副本混搭：降低集群成本的利器

• 細(xì)粒度的主備關(guān)系。傳統(tǒng)的主備大多數(shù)是節(jié)點(diǎn)級(jí)的，由于一個(gè)節(jié)點(diǎn)上保存的數(shù)據(jù)量較大，主備切換的影響很大。在OceanBase中，主備關(guān)系的粒度是分區(qū)級(jí)的，這是一個(gè)很細(xì)的粒度，切換對(duì)業(yè)務(wù)的影響比較小，并且切換是秒級(jí)的。

• 位置信息自動(dòng)刷新。在擴(kuò)容引起分區(qū)位置變化后，在第一次訪問(wèn)原位置時(shí)，系統(tǒng)會(huì)檢測(cè)到變化，并且刷新位置信息來(lái)進(jìn)行重試，執(zhí)行成功后向客戶端返回正確的結(jié)果。除OBServer端以外，OBProxy也會(huì)根據(jù)服務(wù)端的反饋來(lái)更新自己保留的位置信息，后續(xù)的訪問(wèn)就會(huì)被直接路由到正確的節(jié)點(diǎn)而無(wú)需集群內(nèi)部轉(zhuǎn)發(fā)。

擴(kuò)容是在線的，縮容也是如此。

高可用是OceanBase數(shù)據(jù)庫(kù)安身立命的根本，以下三篇文章對(duì)此進(jìn)行了詳細(xì)的描述：

• 傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)高可用的缺失

• 如何在非可靠硬件上實(shí)現(xiàn)金融級(jí)高可用？

• 基于Raft分布式一致性協(xié)議實(shí)現(xiàn)的局限及其對(duì)數(shù)據(jù)庫(kù)的風(fēng)險(xiǎn)

它們包括了“OceanBase和傳統(tǒng)數(shù)據(jù)庫(kù)的差異，以及，在選舉協(xié)議上為什么我們選擇Paxos協(xié)議而不是更容易理解的Raft協(xié)議？”等內(nèi)容。在這里簡(jiǎn)短總結(jié)如下：

• 傳統(tǒng)數(shù)據(jù)庫(kù)高可用依賴專用硬件，而OceanBase是在普通商業(yè)硬件上實(shí)現(xiàn)高可用。

• 傳統(tǒng)數(shù)據(jù)庫(kù)在故障發(fā)生時(shí)缺乏仲裁機(jī)制，需要人在不丟數(shù)據(jù)和不停服務(wù)之間做選擇；OceanBase基于Paxos協(xié)議在少數(shù)派副本故障情況下可以自動(dòng)恢復(fù)，不丟數(shù)據(jù)（RPO＝0），不停服務(wù)（受影響分區(qū)RTO小于30秒）。

• 采用Paxos協(xié)議而不是Raft協(xié)議的原因在于Raft協(xié)議要求日志確認(rèn)必須是順序的，如果前面的某條日志因?yàn)榉N種原因沒有得到確認(rèn)，后面的日志也都不能確認(rèn)。這會(huì)造成一個(gè)嚴(yán)重后果，使得在業(yè)務(wù)邏輯層面不互相依賴的操作產(chǎn)生了互相依賴，對(duì)系統(tǒng)吞吐率有非常大的影響。尤其在高負(fù)載的時(shí)候。這種依賴是業(yè)務(wù)開發(fā)人員和DBA無(wú)法預(yù)測(cè)和規(guī)避的，發(fā)生的時(shí)候也無(wú)法有效解決。

除了異常情況下的可用性，系統(tǒng)升級(jí)、DDL變更等計(jì)劃中的操作也不能影響系統(tǒng)可用性。我們通過(guò)逐個(gè)Zone升級(jí)的方式，實(shí)現(xiàn)升級(jí)過(guò)程的可灰度、可回滾；同時(shí)通過(guò)多個(gè)Zone之間的數(shù)據(jù)一致性校驗(yàn)來(lái)驗(yàn)證新升級(jí)系統(tǒng)的正確性。

通過(guò)實(shí)現(xiàn)多版本的數(shù)據(jù)庫(kù)對(duì)象定義，我們實(shí)現(xiàn)了DDL操作和查詢、更新操作互相不等待。針對(duì)多版本的數(shù)據(jù)庫(kù)對(duì)象定義，多補(bǔ)充一句，DDL操作對(duì)數(shù)據(jù)庫(kù)對(duì)象的影響保證能被對(duì)于同一個(gè)用戶Session后續(xù)的操作看到，哪怕這個(gè)用戶Session對(duì)應(yīng)的是OBProxy到集群不同服務(wù)器的多個(gè)Session。

高性能不僅僅意味著服務(wù)能力強(qiáng)，也意味著成本降低，在相同硬件條件下可以支撐規(guī)模更大的業(yè)務(wù)。OceanBase通過(guò)讀寫分離架構(gòu)（LSM tree），將更新暫存在內(nèi)存中，并且在內(nèi)存中維護(hù)兩種類型的索引：Hash索引和B＋樹索引，分別用來(lái)加速主鍵查詢和索引范圍查詢，達(dá)到準(zhǔn)內(nèi)存數(shù)據(jù)庫(kù)的性能。

和傳統(tǒng)數(shù)據(jù)庫(kù)不同的是：更新操作不是原地進(jìn)行的，沒有傳統(tǒng)數(shù)據(jù)庫(kù)的寫入放大問(wèn)題，對(duì)于一般規(guī)模的系統(tǒng)，內(nèi)存可以放下一天的增量。在系統(tǒng)高負(fù)載運(yùn)行的時(shí)候，幾乎沒有數(shù)據(jù)文件寫，這會(huì)大大減少IO；在系統(tǒng)負(fù)載輕的時(shí)候，將內(nèi)存增量批量合并到持久化存儲(chǔ)上。

除了讀寫分離架構(gòu)帶來(lái)的性能提升外，我們?cè)谡麄€(gè)執(zhí)行鏈路上做了不少優(yōu)化，主要包括如下幾類：

• Cache機(jī)制。在數(shù)據(jù)層面有行緩存和數(shù)據(jù)塊緩存，對(duì)于經(jīng)常訪問(wèn)的數(shù)據(jù)，IO讀大大降低了；在SQL引擎層，有執(zhí)行計(jì)劃緩存。

• JIT編譯執(zhí)行。在表達(dá)式計(jì)算及存儲(chǔ)執(zhí)行過(guò)程中，都支持編譯執(zhí)行，大大加速了大量數(shù)據(jù)行的計(jì)算。

• 自適應(yīng)能力。SQL引擎會(huì)根據(jù)語(yǔ)句操作數(shù)據(jù)的分布情況選擇采用本地、遠(yuǎn)程、分布式執(zhí)行，并基于代價(jià)選擇合適的計(jì)劃。在分布式執(zhí)行的情況下，根據(jù)代價(jià)計(jì)算盡量將計(jì)算下降到節(jié)點(diǎn)。事務(wù)層會(huì)盡量采用本地事務(wù)，減少分布式事務(wù)以提升性能。

• 共享工作線程以及異步化。和傳統(tǒng)數(shù)據(jù)庫(kù)不同的是，OceanBase沒有采用專有工作線程方式，工作線程多Session共享。此外，在語(yǔ)句執(zhí)行過(guò)程以及事務(wù)提交時(shí)，多處采用異步化操作，最大限度地減少了無(wú)謂等待，充分利用CPU。

除上述情況以外，我們還做了很多細(xì)致的工作。整體來(lái)看效果非常明顯：2017年“雙十一”峰值4200萬(wàn)次操作每秒，用戶體驗(yàn)相當(dāng)順滑，系統(tǒng)表現(xiàn)很平穩(wěn)。

OceanBase一方面需要滿足業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)的要求，另一方面也要節(jié)約成本，不僅僅是運(yùn)營(yíng)成本，還包括業(yè)務(wù)遷移和人員學(xué)習(xí)成本。

OceanBase的成本優(yōu)勢(shì)主要來(lái)自以下三點(diǎn)：

• 通過(guò)執(zhí)行路徑性能提升降低計(jì)算成本；

• 通過(guò)讀寫分離架構(gòu)優(yōu)勢(shì)降低存儲(chǔ)成本，一個(gè)真實(shí)的案例是某內(nèi)部業(yè)務(wù)從Oracle遷移到OceanBase，原先的100TB縮小到30幾個(gè)TB。因?yàn)镺ceanBase中可以采用壓縮比更高的壓縮算法，而在Oracle中，由于是原地更新要兼顧性能，沒法采用消耗CPU過(guò)多的高壓縮比壓縮算法；

• 通過(guò)多租戶架構(gòu)，不同負(fù)載類型的業(yè)務(wù)通過(guò)多租戶方式混合部署，能更加充分地利用了機(jī)器資源（可參考：多租戶機(jī)制概述）。從實(shí)際應(yīng)用來(lái)看，采用OceanBase數(shù)據(jù)庫(kù)的金融業(yè)務(wù)，單賬戶成本只有原先的1/5到1/10。

以上的幾個(gè)特點(diǎn)使得OceanBase具有競(jìng)爭(zhēng)優(yōu)勢(shì)，但要將業(yè)務(wù)真正從原系統(tǒng)遷移到OceanBase還需要一個(gè)額外的特性——兼容性。高兼容性使得系統(tǒng)遷移能在可控的成本下進(jìn)行。

對(duì)公司內(nèi)部MySQL業(yè)務(wù)，OceanBase能做到業(yè)務(wù)零修改遷移?？梢赃@么說(shuō)，主流關(guān)系數(shù)據(jù)庫(kù)具備的常用功能OceanBase都具備了。不僅是在語(yǔ)法層面，而且是在用戶體驗(yàn)和業(yè)務(wù)體驗(yàn)上完全一致。

從2017年開始，OceanBase開始服務(wù)外部客戶，我們發(fā)現(xiàn)兼容性做得還不夠，還需要再上一層樓：不僅常用功能要兼容，更要全面兼容；不僅是要兼容MySQL，還要兼容商業(yè)數(shù)據(jù)庫(kù)。只有這樣，才能使得外部業(yè)務(wù)具備零修改遷移OceanBase的可能性。這些工作正是我們目前在做的。

接下來(lái)，OceanBase 2.0版本即將發(fā)布，屆時(shí)也會(huì)在DBAplus社群進(jìn)行新特性的技術(shù)分享。這個(gè)全新的版本在分布式能力和SQL功能上相對(duì)于1.X版本都有質(zhì)的提升，我們也真誠(chéng)希望，OceanBase 2.0能夠讓分布式架構(gòu)對(duì)業(yè)務(wù)透明、讓業(yè)務(wù)更方便地獲得更好的數(shù)據(jù)庫(kù)服務(wù)。