OceanBase 1.0項(xiàng)目從2013年初開(kāi)始做總體設(shè)計(jì),，2014年開(kāi)始編碼,、測(cè)試，2015年底正式上線并無(wú)縫遷移部分集團(tuán)MySQL業(yè)務(wù),，直到2016年中才正式上線螞蟻核心業(yè)務(wù),，包括會(huì)員視圖、花唄,、賬務(wù),，等等，最后“絲般柔順”地通過(guò)了2016年雙十一大考,。

從技術(shù)架構(gòu)的角度看,，一個(gè)分布式數(shù)據(jù)庫(kù)主要就是兩個(gè)部分：一個(gè)部分是怎么做存儲(chǔ)，怎么做事務(wù),；另外一個(gè)部分是怎么做查詢,。首先我們看第一個(gè)部分，主要是三個(gè)關(guān)鍵點(diǎn)：可擴(kuò)展,、高可用以及低成本,，它們代表了OceanBase的核心技術(shù)優(yōu)勢(shì)。

分布式存儲(chǔ)&事務(wù)

第一我們?cè)趺蠢斫鈹?shù)據(jù),，如何把數(shù)據(jù)劃分開(kāi)來(lái)從而分布到多臺(tái)服務(wù)器,？這個(gè)問(wèn)題其實(shí)傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)已經(jīng)幫我們解決好了。無(wú)論是Oracle還是MySQL,，都支持一個(gè)叫做兩級(jí)分區(qū)表的概念,。大部分業(yè)務(wù)都可以按兩個(gè)維度劃分?jǐn)?shù)據(jù)：一個(gè)維度是時(shí)間，數(shù)據(jù)是按照時(shí)間順序生成的,；另外一個(gè)維度，對(duì)于互聯(lián)網(wǎng)業(yè)務(wù)來(lái)講,，往往就是用戶,。不同的用戶生成不同的數(shù)據(jù)，不同用戶之間的數(shù)據(jù)相關(guān)度比較低,，而同一個(gè)用戶的數(shù)據(jù)往往會(huì)被同時(shí)訪問(wèn),。

圖1 OceanBase數(shù)據(jù)分布

如圖1，通過(guò)時(shí)間和業(yè)務(wù)主鍵兩個(gè)維度將表格劃分為P1~P8總共8個(gè)分區(qū),。OceanBase跟傳統(tǒng)數(shù)據(jù)庫(kù)不一樣的地方在哪里呢,？傳統(tǒng)數(shù)據(jù)庫(kù)所有的分區(qū)只能在一臺(tái)服務(wù)器，而OceanBase每個(gè)分區(qū)可以分布到不同的服務(wù)器,。從數(shù)據(jù)模型的角度看,，OceanBase可以被認(rèn)為是傳統(tǒng)的數(shù)據(jù)庫(kù)分區(qū)表在多機(jī)的實(shí)現(xiàn)。對(duì)于常見(jiàn)的分布式系統(tǒng)，要么采用哈希分區(qū),，要么采用范圍分區(qū),。OceanBase的數(shù)據(jù)劃分方案和這些系統(tǒng)有較大的差別，通過(guò)兩級(jí)分區(qū)表,，我們可以把不同的用戶,，以及在不同時(shí)間點(diǎn)生成的數(shù)據(jù)全部融合到統(tǒng)一的表格里面。無(wú)論這些分區(qū)在在多臺(tái)服務(wù)器上是如何分布的,，甚至可以對(duì)在線數(shù)據(jù)采用內(nèi)存計(jì)算,，對(duì)歷史數(shù)據(jù)采用更高壓縮率的壓縮算法或者執(zhí)行預(yù)計(jì)算，整個(gè)系統(tǒng)對(duì)使用者呈現(xiàn)的都是一張表格,，后臺(tái)實(shí)現(xiàn)對(duì)使用者完全透明,。當(dāng)然，這里面還會(huì)有很多的工作要做,。

第二點(diǎn)是我們底層的分布式架構(gòu),。

圖2 OceanBase整體架構(gòu)

圖2是OceanBase整體架構(gòu)圖。OceanBase架構(gòu)圖往往都是三個(gè)框框,。為什么這樣呢,？這是基于高可用考慮的。為了實(shí)現(xiàn)機(jī)房故障無(wú)損容災(zāi),，OceanBase需要部署到三個(gè)機(jī)房,。每個(gè)機(jī)房又會(huì)有很多服務(wù)器，每臺(tái)服務(wù)器又會(huì)服務(wù)很多不同的分區(qū),。如圖2,， P1到P8代表不同的分區(qū)，每個(gè)分區(qū)有3個(gè)副本,，分布在三個(gè)機(jī)房?jī)?nèi),。用戶的請(qǐng)求首先發(fā)給ObProxy。ObProxy是一個(gè)訪問(wèn)代理,，它會(huì)根據(jù)用戶請(qǐng)求的數(shù)據(jù)將請(qǐng)求轉(zhuǎn)發(fā)到合適的服務(wù)器,。ObProxy的最大的亮點(diǎn)在于性能特別好，我們對(duì)它做了非常多的針對(duì)性優(yōu)化,，使得它可以在非常一般的普通服務(wù)器上達(dá)到每秒百萬(wàn)級(jí)的處理能力,。ObServer是OceanBase的工作機(jī)，每臺(tái)工作機(jī)服務(wù)一些分區(qū),。

與大多數(shù)分布式系統(tǒng)不同的地方在于,，OceanBase這個(gè)系統(tǒng)沒(méi)有單獨(dú)的總控服務(wù)器/總控進(jìn)程。分布式系統(tǒng)一般包含一個(gè)單獨(dú)的總控進(jìn)程,，用來(lái)做全局管理,、負(fù)載均衡,，等等。OceanBase沒(méi)有單獨(dú)的總控進(jìn)程,，我們的總控是一個(gè)服務(wù),，叫做RootService，集成在ObServer里面,。OceanBase會(huì)從所有的工作機(jī)中動(dòng)態(tài)地選出一臺(tái)ObServer執(zhí)行總控服務(wù),，另外，當(dāng)總控服務(wù)所在的ObServer出現(xiàn)故障時(shí),，系統(tǒng)會(huì)自動(dòng)選舉一臺(tái)新的ObServer提供總控服務(wù),。這種方式的好處在于簡(jiǎn)化部署，雖然實(shí)現(xiàn)很復(fù)雜,，但是大大降低了使用成本,。

接下來(lái)我們看整個(gè)數(shù)據(jù)庫(kù)最核心的部分。

數(shù)據(jù)庫(kù)最基礎(chǔ),，也是最核心的部分是事務(wù)處理,，這點(diǎn)對(duì)于多機(jī)系統(tǒng)尤其重要。

如果只是操作單個(gè)分區(qū),，因?yàn)閱蝹€(gè)分區(qū)一定只能由一臺(tái)服務(wù)器提供服務(wù),，本質(zhì)上是一個(gè)單機(jī)的事務(wù)，OceanBase的實(shí)現(xiàn)機(jī)制和Oracle,、MySQL這樣的傳統(tǒng)數(shù)據(jù)庫(kù)原理類似,，也是多版本并發(fā)控制。不同點(diǎn)在于,，OceanBase做了一些針對(duì)內(nèi)存數(shù)據(jù)庫(kù)的優(yōu)化,，主要有兩點(diǎn)：

1. 日志同步。因?yàn)橐龈呖捎?，一定要做日志的?qiáng)同步,。OceanBase之所以既能做到高可用，又能做到高性能,，是因?yàn)槲覀冏隽撕芏噌槍?duì)日志強(qiáng)同步的優(yōu)化,，包括異步化、并行,，等等；

2. 內(nèi)存數(shù)據(jù)庫(kù),。OceanBase借鑒了內(nèi)存數(shù)據(jù)庫(kù)的設(shè)計(jì)思路,，實(shí)現(xiàn)了無(wú)鎖數(shù)據(jù)結(jié)構(gòu)、內(nèi)存多版本并發(fā)控制,、SQL編譯執(zhí)行等優(yōu)化手段,。

如果操作多個(gè)分區(qū),，這又分成兩種情況：

1. 多個(gè)分區(qū)在同一臺(tái)服務(wù)器。由于多個(gè)分區(qū)在一臺(tái)服務(wù)器,，本質(zhì)上也是單機(jī)事務(wù),，實(shí)現(xiàn)方案與之前提到的單分區(qū)事務(wù)類似。

2. 多個(gè)分區(qū)分布在多臺(tái)服務(wù)器上,。由于多個(gè)分區(qū)跨ObServer,，OceanBase內(nèi)部通過(guò)兩階段提交實(shí)現(xiàn)分布式事務(wù)。當(dāng)然,，兩階段提交協(xié)議性能較差,，OceanBase內(nèi)部做了很多優(yōu)化。首先,，我們提出了一個(gè)表格組的概念,，也就是說(shuō)，我們會(huì)把多個(gè)經(jīng)常一起訪問(wèn),，或者說(shuō)訪問(wèn)模式比較類似的表格放到一個(gè)表格組里面,。與此同時(shí)，OceanBase后臺(tái)會(huì)將同一個(gè)表格組盡可能調(diào)度到一臺(tái)服務(wù)器上,，避免分布式事務(wù),。接下來(lái)的優(yōu)化手段涉及到兩階段提交協(xié)議的內(nèi)部實(shí)現(xiàn)。兩階段提交協(xié)議涉及多臺(tái)服務(wù)器,，協(xié)議中包含協(xié)調(diào)者,、參與者這兩種角色，參與者維護(hù)了每臺(tái)服務(wù)器的局部狀態(tài),，協(xié)調(diào)者維護(hù)了分布式事務(wù)的全局狀態(tài),。常見(jiàn)的做法是對(duì)協(xié)調(diào)者記日志來(lái)持久化分布式事務(wù)的全局狀態(tài)，而OceanBase沒(méi)有這么做,。如果協(xié)調(diào)者出現(xiàn)故障,，OceanBase通過(guò)查詢所有參與者的狀態(tài)來(lái)恢復(fù)分布式事務(wù)。通過(guò)這種方式節(jié)省了協(xié)調(diào)者日志,，而且只要所有的參與者都預(yù)提交成功,，整個(gè)事務(wù)就成功了，不需要等協(xié)調(diào)者寫日志就可以應(yīng)答客戶端,。

OceanBase里面高可用是基于Paxos協(xié)議實(shí)現(xiàn)的,。Google Chubby系統(tǒng)的發(fā)明者說(shuō)過(guò)一句話，這個(gè)世界上所有的高可用強(qiáng)一致的協(xié)議都是Paxos或者Paxos的變種,，我們也認(rèn)為一切不是Paxos協(xié)議實(shí)現(xiàn)的高可用機(jī)制都是耍流氓,。

圖3 OceanBase高可用原理

如圖3，OceanBase最底層的技術(shù)就是通過(guò)Paxos協(xié)議實(shí)現(xiàn)的分布式選舉和多庫(kù)多活,。Paxos協(xié)議的好處在于節(jié)點(diǎn)是多活的,，當(dāng)服務(wù)節(jié)點(diǎn)出現(xiàn)故障時(shí),，其它正常的節(jié)點(diǎn)可以在幾秒內(nèi)替代這個(gè)故障的節(jié)點(diǎn)，很快恢復(fù)服務(wù),，而且完全不丟數(shù)據(jù),。Paxos協(xié)議同時(shí)實(shí)現(xiàn)了高可用和強(qiáng)一致，這是很牛的,。當(dāng)然除了最底層核心的Paxos協(xié)議,，OceanBase還會(huì)通過(guò)分布式調(diào)度將同一個(gè)分區(qū)的不同副本調(diào)度多多個(gè)機(jī)房，而不是在一個(gè)機(jī)房或者一個(gè)機(jī)架里面,。當(dāng)服務(wù)器出現(xiàn)故障,，OceanBase客戶端能夠很快自動(dòng)感知到，并把服務(wù)切到?jīng)]有故障的服務(wù)器上,。通過(guò)這一系列組合拳,，OceanBase真正做到了持續(xù)可用。

圖4 高可用：OceanBase VS Oracle

圖4是OceanBase和Oracle的高可用能力對(duì)比,。

1. 單個(gè)節(jié)點(diǎn)故障,，相比Oracle RAC，OceanBase單個(gè)節(jié)點(diǎn)故障的影響會(huì)小一些,，為什么,？因?yàn)镺ceanBase的集群規(guī)模往往會(huì)比較大，單個(gè)節(jié)點(diǎn)的故障只影響很小一部分?jǐn)?shù)據(jù),。另外,，OceanBase的恢復(fù)速度也會(huì)更快。OceanBase采用基線加增量的存儲(chǔ)引擎,，最熱的增量數(shù)據(jù)都是全部在內(nèi)存的,。當(dāng)主庫(kù)出現(xiàn)故障，備庫(kù)只需要把最后一部分未完成的日志回放出來(lái)就能夠提供服務(wù),，非?？臁６鳲racle底層存儲(chǔ)是基于頁(yè)面的,，它需要逐步恢復(fù)頁(yè)面,，這個(gè)過(guò)程相對(duì)更長(zhǎng)。

2. 機(jī)房整體故障,。OceanBase在螞蟻都是三機(jī)房部署的,，當(dāng)一個(gè)機(jī)房出現(xiàn)故障，OceanBase也能夠做到幾十秒恢復(fù),，和單個(gè)節(jié)點(diǎn)故障的恢復(fù)速度基本相當(dāng),。但是，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)，即使是Oracle也做不到,，Oracle RAC不太可能部署到多個(gè)機(jī)房的。

接下來(lái)我們看看OceanBase的性能,。長(zhǎng)遠(yuǎn)來(lái)看,，性能取決于底層的引擎如何設(shè)計(jì)，而OceanBase的引擎跟傳統(tǒng)數(shù)據(jù)庫(kù)的引擎有較大的差別,。

圖5：兩類數(shù)據(jù)庫(kù)引擎

在互聯(lián)網(wǎng)里面能夠看到各種各樣的存儲(chǔ)系統(tǒng),，引擎非常多，我認(rèn)為基本可以分為兩個(gè)大類,。如圖5,，第一類是傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)引擎。關(guān)系數(shù)據(jù)庫(kù)本質(zhì)上是面向磁盤設(shè)計(jì)的,，它把數(shù)據(jù)分成很多很多的頁(yè)面,，通過(guò)頁(yè)面緩存機(jī)制來(lái)管理頁(yè)面，底層的索引是B 樹(shù),。這種引擎發(fā)展得非常成熟,，但是寫入性能差，原因是關(guān)系數(shù)據(jù)庫(kù)的寫入放大效應(yīng),。用戶數(shù)據(jù)是按行寫入的,，但是關(guān)系數(shù)據(jù)庫(kù)卻是按頁(yè)面管理的，有時(shí)只寫了一行數(shù)據(jù),，卻不得不把整個(gè)頁(yè)面刷入磁盤,。另外一類互聯(lián)網(wǎng)公司流行的引擎是LSM樹(shù)。Google里面有一個(gè)很有名的開(kāi)源系統(tǒng)LevelDB,，F(xiàn)acebook基于它又開(kāi)發(fā)了一個(gè)類似的系統(tǒng)RocksDB,。這種引擎采用基線加增量的設(shè)計(jì)，數(shù)據(jù)首先以增量的形式寫入到內(nèi)存中,，當(dāng)增量達(dá)到一個(gè)閥值時(shí)統(tǒng)一寫到磁盤,。這種做法的好處是解決了關(guān)系數(shù)據(jù)庫(kù)寫入放大的問(wèn)題，但是它的合并代價(jià)會(huì)比較大,，可能出現(xiàn)合并速度趕不上內(nèi)存寫入的情況,。

圖6 OceanBase存儲(chǔ)引擎

OceanBase本質(zhì)上是一個(gè)基線加增量的存儲(chǔ)引擎，跟關(guān)系數(shù)據(jù)庫(kù)差別很大,，但是我們借鑒了傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)對(duì)引擎進(jìn)行了優(yōu)化,。如圖6，第一個(gè)優(yōu)化就是合并性能的優(yōu)化,，傳統(tǒng)數(shù)據(jù)庫(kù)把數(shù)據(jù)分成很多頁(yè)面,，我們也借鑒了傳統(tǒng)數(shù)據(jù)庫(kù)的思想，把數(shù)據(jù)分成很多2MB為單位的宏塊,。執(zhí)行合并時(shí),，如果只有一部分?jǐn)?shù)據(jù)修改,，那么，只需要合并那些修改過(guò)的宏塊,，而不是把所有沒(méi)有修改的宏塊也一起合并,。通過(guò)這個(gè)方式，OceanBase的合并代價(jià)相比LevelDB和RocksDB都會(huì)低很多,，這是第一點(diǎn),。第二，我們會(huì)利用OceanBase的分布式機(jī)制做優(yōu)化,。在多機(jī)系統(tǒng)中,，數(shù)據(jù)一定是存在多個(gè)副本。OceanBase實(shí)現(xiàn)了一個(gè)稱為輪轉(zhuǎn)合并的機(jī)制,。當(dāng)主副本提供服務(wù)時(shí),，其它副本可以執(zhí)行合并；等到其它副本合并完成以后,，原來(lái)的主副本接著合并,，并把流量切到已經(jīng)合并完成的副本。通過(guò)這種方式,，OceanBase把正常服務(wù)和合并時(shí)間錯(cuò)開(kāi),，使得合并操作對(duì)正常用戶請(qǐng)求完全沒(méi)有干擾。

由于OceanBase采用基線加增量的設(shè)計(jì),，一部分?jǐn)?shù)據(jù)在基線,，一部分在增量，原理上每次查詢都是既要讀基線,，也要讀增量,。為此，OceanBase做了很多的優(yōu)化,，尤其是針對(duì)單行的優(yōu)化,。OceanBase內(nèi)部把很多小查詢的結(jié)果緩存在內(nèi)存里面，以行為單位,，而不是以塊為單位,。行緩存包括兩個(gè)部分，如果這個(gè)行存在,，緩存這個(gè)行的原始數(shù)據(jù),；否則，緩存布隆過(guò)濾器,。OLTP業(yè)務(wù)大部分操作為小查詢,，通過(guò)小查詢優(yōu)化，OceanBase避免了傳統(tǒng)數(shù)據(jù)庫(kù)解析整個(gè)數(shù)據(jù)塊的開(kāi)銷，達(dá)到了接近內(nèi)存數(shù)據(jù)庫(kù)的性能,。另外,，由于基線是只讀數(shù)據(jù)，而且內(nèi)部采用連續(xù)存儲(chǔ)的方式,，OceanBase可以采用比較激進(jìn)的壓縮算法,，既能做到高壓縮比，又不影響查詢性能,，大大降低了成本。

圖7 SQL-VM

多租戶隔離有不同的實(shí)現(xiàn)方式,，這些實(shí)現(xiàn)方式的效果是類似的,。最傳統(tǒng)的實(shí)現(xiàn)方式是虛擬機(jī)。這種方案比較成熟,，在云環(huán)境也經(jīng)常使用,，然而，這種方案比較重量級(jí),，開(kāi)銷比較大,。另外一種最近比較流行的技術(shù)類似Google Cgroup這樣的輕量級(jí)隔離技術(shù)，或者一些Cgroup衍生的技術(shù),，比如Docker,。OceanBase的隔離方式很不一樣，我們采用的是在數(shù)據(jù)庫(kù)內(nèi)部做了一個(gè)SQL虛擬機(jī),。

為什么這么做呢,？這種做法在業(yè)內(nèi)也是有例可尋的，例如Oracle 12c以及Azure SQL Server,。它的好處是DB內(nèi)把很多業(yè)務(wù)統(tǒng)一的管理,，會(huì)把整個(gè)管理機(jī)制做得對(duì)用戶特別透明。另外,，隔離的開(kāi)銷比較低,，單臺(tái)服務(wù)器可以服務(wù)更多的租戶，降低云服務(wù)的整體成本,。

圖8 OceanBase多租戶原理

OceanBase是分布式系統(tǒng),，多租戶除了單機(jī)層面怎么做隔離，還涉及到在多機(jī)層面如何做調(diào)度,。如圖8,，在OceanBase中，有的租戶比較小,，位于一臺(tái)服務(wù)器上,，例如租戶B或者租戶C；有的租戶比較大，位于多臺(tái)服務(wù)器上,，例如租戶A,。圖8中的租戶A在每臺(tái)服務(wù)器上有一個(gè)資源容器，限制了該租戶能夠使用的CPU,、網(wǎng)絡(luò),、內(nèi)存、IOPS等系統(tǒng)資源,。OceanBase的負(fù)載均衡分為兩個(gè)層面：第一個(gè)層面是租戶負(fù)載均衡,，它的原理就是把每個(gè)租戶的資源容器分布到很多臺(tái)ObServer上面去；第二個(gè)層面是分區(qū)負(fù)載均衡,，如果租戶只在一臺(tái)服務(wù)器,，第二個(gè)層面是沒(méi)有必要的。如果租戶在多臺(tái)服務(wù)器上,，需要把這個(gè)租戶的分區(qū)均勻地分布到它的資源容器中,。OceanBase內(nèi)部會(huì)盡量使得小租戶只在一臺(tái)服務(wù)器上，避免分布式事務(wù),。當(dāng)租戶需要的資源逐步增加時(shí),，OceanBase也能做到自動(dòng)擴(kuò)展，對(duì)用戶是透明的,。

SQL-VM是OceanBase實(shí)現(xiàn)的資源隔離方案,，分為三個(gè)部分：CPU、IO還有內(nèi)存,，網(wǎng)絡(luò)目前還不是瓶頸,，我們做得比較少。CPU隔離是基于時(shí)間片的主動(dòng)調(diào)度,，跟操作系統(tǒng)的調(diào)度比較類似,。IO隔離我們借鑒了虛擬機(jī)隔離方案，采用基于Deadline和優(yōu)先級(jí)的隔離算法,。這里最大的難點(diǎn)在于既要把資源的利用率提高,，又要做到盡可能公平，這兩個(gè)目標(biāo)本身是矛盾的,。內(nèi)存隔離基本上是兩個(gè)機(jī)制,，一個(gè)機(jī)制是怎么做內(nèi)存的限制，另外一個(gè)機(jī)制是怎么做公平擠占算法,。

分布式查詢

用戶的請(qǐng)求首先會(huì)發(fā)送到一臺(tái)稱為ObProxy的代理服務(wù)器,，它的功能就是一個(gè)透明轉(zhuǎn)發(fā)的代理服務(wù)。ObProxy會(huì)解析SQL,，識(shí)別SQL操作哪個(gè)分區(qū),，然后把該SQL轉(zhuǎn)發(fā)到它所操作的分區(qū)所在的服務(wù)器,。

圖9 ObProxy原理

如圖9，可以看到,，如果SQL請(qǐng)求操作分區(qū)P2,，ObProxy就會(huì)轉(zhuǎn)發(fā)到左邊的服務(wù)器；如果涉及到多個(gè)分區(qū),，例如同時(shí)操作P1,、P4，由于它們位于不同的服務(wù)器,，ObProxy就會(huì)隨機(jī)或者根據(jù)負(fù)載選擇一臺(tái)服務(wù)器,。

ObProxy最大的亮點(diǎn)還是在于它的性能。世面上有很多數(shù)據(jù)庫(kù)代理服務(wù)方案,，ObProxy的性能是其中的佼佼者,。我們實(shí)現(xiàn)了大量的優(yōu)化技術(shù)，包括：

1. 輕量級(jí)SQL Parser,。如果采用傳統(tǒng)的數(shù)據(jù)庫(kù)SQL解析框架，性能肯定是不高的,，OceanBase做了大量的手工解析工作,。

2. 異步框架。ObProxy是全異步框架,，無(wú)論是SQL轉(zhuǎn)發(fā),，還是網(wǎng)絡(luò)收發(fā)包，所有操作都是全異步的,，從而把CPU利用到極致,。

3. 可擴(kuò)展性。ObProxy內(nèi)部會(huì)使得對(duì)一個(gè)請(qǐng)求的轉(zhuǎn)發(fā)盡可能做到每一個(gè)線程內(nèi)部,，避免跨線程訪問(wèn)或者訪問(wèn)全局的數(shù)據(jù)結(jié)構(gòu),。我們基本上做到每個(gè)請(qǐng)求都是在一個(gè)線程內(nèi)完成的，ObProxy可以做到隨著CPU核心完全線性擴(kuò)展,。

除了性能卓越之外,，ObProxy還實(shí)現(xiàn)了在實(shí)際生產(chǎn)系統(tǒng)非常關(guān)鍵的運(yùn)維特性。第一個(gè)運(yùn)維特性是熱升級(jí),，ObProxy的升級(jí)對(duì)使用者是無(wú)感知的,。升級(jí)過(guò)程中，ObProxy內(nèi)部會(huì)有兩個(gè)版本,，新的請(qǐng)求會(huì)由新的版本提供服務(wù),，老的請(qǐng)求由老的版本提供服務(wù)，過(guò)了很長(zhǎng)時(shí)間才會(huì)把老版本退出,。另外一個(gè)運(yùn)維特性是全鏈路監(jiān)控,，ObProxy作為用戶使用OceanBase的入口,，和服務(wù)端一起聯(lián)合實(shí)現(xiàn)了全鏈路監(jiān)控功能。

當(dāng)SQL請(qǐng)求到了ObServer服務(wù)端,，經(jīng)過(guò)SQL解析,、重寫、優(yōu)化等一系列過(guò)程后,，再由SQL執(zhí)行器來(lái)負(fù)責(zé)執(zhí)行,。分為三種情況：

1. 本地計(jì)劃。如果ObProxy請(qǐng)求轉(zhuǎn)發(fā)對(duì)了,，轉(zhuǎn)發(fā)的位置就是分區(qū)所在的ObServer,，這是個(gè)本地請(qǐng)求，其執(zhí)行方式和傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)相同,。

2. 遠(yuǎn)程計(jì)劃,。SQL請(qǐng)求只操作一個(gè)分區(qū)，但是ObProxy應(yīng)用緩存的信息失效,，或者出現(xiàn)一些BUG,，把請(qǐng)求轉(zhuǎn)發(fā)到另外一個(gè)服務(wù)器。OceanBase會(huì)自動(dòng)發(fā)現(xiàn)這一點(diǎn),，并把SQL當(dāng)成遠(yuǎn)程計(jì)劃來(lái)處理,，即內(nèi)部把SQL執(zhí)行計(jì)劃發(fā)到另外一臺(tái)有數(shù)據(jù)的服務(wù)器，等那臺(tái)服務(wù)器計(jì)算出結(jié)果再返回,。

3. 分布式計(jì)劃,。如果SQL請(qǐng)求涉及的數(shù)據(jù)在多臺(tái)服務(wù)器，需要走分布式計(jì)劃,。這種請(qǐng)求涉及的數(shù)據(jù)量往往比較大,，OceanBase后臺(tái)會(huì)做并行處理，比如說(shuō)對(duì)任務(wù)做拆分,，對(duì)每個(gè)子任務(wù)的結(jié)果做合并,、處理并發(fā)、限制并發(fā)數(shù),，等等,。基本上可以這么講,，在并行數(shù)據(jù)庫(kù)或者OLAP分析型數(shù)據(jù)庫(kù)看到的東西,，在OceanBase的分布式計(jì)劃中都有。

經(jīng)驗(yàn)&思考

第一點(diǎn)關(guān)于高可用,。首先,，我認(rèn)為強(qiáng)一致加高可用是未來(lái)云數(shù)據(jù)庫(kù)的標(biāo)配。我們以前做應(yīng)用架構(gòu)和存儲(chǔ)選型的時(shí)候會(huì)談很多東西,，比如數(shù)據(jù)庫(kù)異步復(fù)制提高性能,，或者CAP理論導(dǎo)致一致性和高可用不可兼得,，等等。然而,，通過(guò)OceanBase的實(shí)踐我們也已經(jīng)得出一個(gè)結(jié)論,，實(shí)現(xiàn)強(qiáng)一致相比實(shí)現(xiàn)弱一致性能開(kāi)銷不是那么大，性能的損耗比較低,，而且可以獲得非常多的好處,，這一定是以后的趨勢(shì)。另外,，實(shí)現(xiàn)云數(shù)據(jù)庫(kù)級(jí)別的高可用底層一定要用Paxos協(xié)議,，回避該協(xié)議的實(shí)現(xiàn)方案本質(zhì)上都是耍流氓。目前我們已經(jīng)從各大互聯(lián)網(wǎng)公司,，包括Google,、Amazon以及Alibaba的云數(shù)據(jù)庫(kù)實(shí)踐看到了這一趨勢(shì)。

第二點(diǎn)關(guān)于自動(dòng)化,。以前傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)規(guī)模往往比較小,，只有少數(shù)幾臺(tái)機(jī)器，有一個(gè)DBA運(yùn)維就夠了,。然而,，在云數(shù)據(jù)庫(kù)時(shí)代，一定要做規(guī)?；\(yùn)維,，一個(gè)DBA對(duì)幾千甚至上萬(wàn)機(jī)器,，達(dá)到這個(gè)量級(jí)一定要做自動(dòng)化,。強(qiáng)一致是自動(dòng)化的前提，沒(méi)有強(qiáng)一致很難自動(dòng)化,，主庫(kù)故障備庫(kù)會(huì)丟數(shù)據(jù),，自動(dòng)化是很難的。雖然每次宕機(jī)概率很低,，但是規(guī)模上來(lái)概率就高了,。

另外云數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候也會(huì)有很多不一樣的考慮，盡可能地減少人工干預(yù),。例如數(shù)據(jù)庫(kù)配置項(xiàng),，或者比較流行的SQL Hint，在云數(shù)據(jù)庫(kù)時(shí)代一定需要盡可能減少,。系統(tǒng)設(shè)計(jì)者需要在服務(wù)端自己消化,，不要把靈活性留給運(yùn)維的人員，因?yàn)檫\(yùn)維的人要做的就是規(guī)?；\(yùn)維,。

最后一點(diǎn)關(guān)于成本,。成本是云的關(guān)鍵，很多用戶上云就是為了節(jié)省成本,。首先,，性能不等于成本。性能雖然很重要,，但是成本需要考慮更多的因素,，性能、壓縮比,、利用率,、規(guī)模化運(yùn)維,，等等,。以利用率為例，云數(shù)據(jù)庫(kù)的一個(gè)成本節(jié)省利器就是提高機(jī)器利用率,。在云數(shù)據(jù)庫(kù)中,，可以通過(guò)分布式方案把整個(gè)利用率提高來(lái)，即使單機(jī)性能類似,，但是利用率提上來(lái)以后,，成本會(huì)特別的低。

最后是OceanBase的存儲(chǔ)引擎跟傳統(tǒng)數(shù)據(jù)庫(kù)有很大的區(qū)別,，是基線加增量引擎,，這種引擎有特別多的好處，能夠比較完美地解決OLTP和OLAP業(yè)務(wù)融合的問(wèn)題,。如果實(shí)現(xiàn)得當(dāng),，把這種引擎的缺陷規(guī)避地比較好，能夠收獲大量的好處,，相信也是未來(lái)的趨勢(shì),。