本文作者為螞蟻金服OceanBase團(tuán)隊(duì)資深技術(shù)專家顏然，他也是OceanBase初創(chuàng)成員之一，目前負(fù)責(zé)事務(wù)引擎以及性能優(yōu)化方面的研發(fā)工作。

OceanBase是完全自主研發(fā)的金融級(jí)分布式關(guān)系數(shù)據(jù)庫 ，從架構(gòu)上可以通過擴(kuò)展機(jī)器來解決集群服務(wù)能力的擴(kuò)展需求。

OceanBase采用多副本復(fù)制的方案解決了可靠性和可用性的需求，而且構(gòu)建在普通PC服務(wù)器上，不依賴于高端引擎。

我們的目標(biāo)是在普通硬件上提供極限性能的數(shù)據(jù)庫服務(wù)。那么，OceanBase的存儲(chǔ)引擎有什么特點(diǎn)呢？

OceanBase的存儲(chǔ)引擎類似于LSMTree，所有新增的修改都會(huì)先記錄在Memtable中，這些數(shù)據(jù)的變更并不會(huì)實(shí)時(shí)寫到磁盤上，而會(huì)在后臺(tái)定期寫到硬盤上。

不管是磁盤還是SSD，當(dāng)有大量寫入的時(shí)候，它的讀取性能都會(huì)受到很大影響。從一開始OceanBase的架構(gòu)就是為了適應(yīng)這種硬件的特性，所以沒有隨機(jī)寫的操作，對(duì)于SSD和磁盤都很友好，可以將硬盤的吞吐量?jī)?yōu)勢(shì)發(fā)揮出來，把硬件資源最好的性能壓榨出來。

OceanBase從0.x版本到1.x版本，再到現(xiàn)在的2.0版本，一直在推動(dòng)的一件事就是把硬件的性能做到極致，希望在同樣的硬件條件下能給業(yè)務(wù)帶來更多性能的空間。OceanBase的目標(biāo)一直是有極致性能并且性價(jià)比最好的數(shù)據(jù)庫。

從用戶使用角度來看，數(shù)據(jù)庫有兩個(gè)重要的指標(biāo)，延遲（Latency）和吞吐量（Throughput）。這是兩個(gè)非常不一樣的指標(biāo)。

根據(jù)排隊(duì)論模型，這兩者之間的關(guān)系如上圖所示： 隨著吞吐量增加，延遲近似指數(shù)倍增長(zhǎng) 。

當(dāng)整體系統(tǒng)的性能不是特別高的時(shí)候，可以保持延遲的穩(wěn)定性。當(dāng)系統(tǒng)性能壓力很高的情況下，延遲會(huì)增加，我們要做的事情就是要在一個(gè)合理的延遲情況下，讓吞吐量可以盡可能大。換句話說，其實(shí)就是把一個(gè)請(qǐng)求要做的事情盡可能的減少，然后讓單位時(shí)間內(nèi)能做的請(qǐng)求盡可能的多。 性能優(yōu)化的最終目標(biāo)就是在延遲可以接受的場(chǎng)景下，盡可能提高系統(tǒng)的吞吐量。

性能優(yōu)化工作

在剛剛過去的2018年天貓雙11中，成交額2135億再次創(chuàng)造了新紀(jì)錄。那么在螞蟻金服/支付寶這樣的場(chǎng)景下，支付的壓力會(huì)全部落在OceanBase 2.0版本上。在2.0版本里我們做了一個(gè)很重要的事情來進(jìn)一步壓榨硬件的性能—— 也就是在去年同樣機(jī)器數(shù)量的情況下，來支撐今年的流量洪峰。

在同樣的硬件環(huán)境，同樣的機(jī)器規(guī)模數(shù)這些條件下，通過升級(jí)的服務(wù)器版本以及服務(wù)器的部署方式，來提供今年雙11在0:00:00洪峰到來時(shí)的抗壓能力。 雙11的支付壓力是典型的OLTP模型，有大量的增刪改查操作。OceanBase的存儲(chǔ)模型決定了操作主要在內(nèi)存中進(jìn)行，所以在滿負(fù)荷運(yùn)轉(zhuǎn)下CPU是主要瓶頸。

CPU的資源如何壓榨到極致，其實(shí)主要包含兩方面的工作：

• 一是 優(yōu)化語句執(zhí)行消耗指令數(shù)（Instructions /SQL） ，即每個(gè)請(qǐng)求需要執(zhí)行的指令數(shù)，指令越少越好；

• 二是 優(yōu)化系統(tǒng)執(zhí)行指令的效率（Cycles /Instruction） ，可以用CPI（Cyclesper Instruction）表示。

系統(tǒng)性能由每一行代碼決定

任何一段代碼都可能導(dǎo)致bug，任何一行代碼也都有性能優(yōu)化的空間。針對(duì)不同的場(chǎng)景，我們需要深入到每行代碼里去看可以做什么樣的優(yōu)化。

OceanBase 2.0版本進(jìn)行了深度的優(yōu)化獲得了很好的性能提升。上圖所列的只是其中一部分優(yōu)化工作。性能優(yōu)化是一個(gè)事無巨細(xì)的工作，有點(diǎn)類似于測(cè)試工作，本質(zhì)上每一行代碼都會(huì)影響系統(tǒng)的性能。

Commit異步化

在OceanBase已有的模型里，網(wǎng)絡(luò)模塊有單獨(dú)的線程池負(fù)責(zé)和客戶端通信，接受用戶請(qǐng)求和返回請(qǐng)求結(jié)果。接收到的請(qǐng)求會(huì)發(fā)在任務(wù)隊(duì)列中由工作線程處理。

相比較于每一個(gè)用戶的連接使用一個(gè)獨(dú)立的線程服務(wù)的模型，OceanBase的模型可以大大減少上下文切換的次數(shù)。

對(duì)于SQL語句的執(zhí)行，這已經(jīng)是一個(gè)很好的模型了。但是對(duì)于事務(wù)的提交操作，需要將日志在本地持久化和發(fā)送到其他副本持久化，提交操作又會(huì)使得工作線程出現(xiàn)等待的情況。

Commit異步化是在事務(wù)提交日志后不再等待日志持久化，工作線程可以直接去隊(duì)列中取下一個(gè)任務(wù)執(zhí)行。等日志持久化完成后，通過回調(diào)的方式出發(fā)事務(wù)提交完成的操作和給用戶發(fā)送請(qǐng)求的結(jié)果。

擴(kuò)展性問題

我們做了很多事情讓系統(tǒng)少做無謂的事情，多做有用的事情，也就是增加CPU做有效工作的時(shí)間占比。

機(jī)器的CPU核數(shù)越來越多，從原來的幾十個(gè)核和現(xiàn)在的一百多個(gè)核，在英特爾的PC Server上都是很常見的場(chǎng)景。系統(tǒng)在服務(wù)器上運(yùn)行，多核CPU的擴(kuò)展性是一個(gè)很重要的方面。這里以計(jì)數(shù)器場(chǎng)景舉例，單個(gè)線程和多個(gè)線程一起操作同一個(gè)計(jì)數(shù)器，后者因?yàn)槎鄠€(gè)核之間競(jìng)爭(zhēng)同一個(gè)內(nèi)存單元，性能會(huì)下降幾百倍。其實(shí)有時(shí)候人多不一定力量大，人多也有可能導(dǎo)致大家一起搶賽道。

在系統(tǒng)中也大量存在類似的競(jìng)爭(zhēng)場(chǎng)景，內(nèi)存分配器是一個(gè)常見場(chǎng)景。多個(gè)線程在操作同一個(gè)memtable時(shí)，會(huì)從連續(xù)的內(nèi)存塊中分配內(nèi)存，分配內(nèi)存的操作就好似計(jì)數(shù)器的競(jìng)爭(zhēng)。所以，要把memtable的內(nèi)存分配操作做成分區(qū)的形式，減少多個(gè)核之間的競(jìng)爭(zhēng)。

說到底性能優(yōu)化其實(shí)就是在優(yōu)化系統(tǒng)的各個(gè)細(xì)節(jié)，每個(gè)細(xì)節(jié)都要做到極致，最終性能才能壓榨到最好的那個(gè)點(diǎn)，才能把硬件本身的性能發(fā)揮到最好。

性能無止境

我們可以看到，藍(lán)色塊代表的是OceanBase 1.4版本，也就是我們現(xiàn)在使用的主力版本，綠色塊代表了OceanBase 2.0版本。A場(chǎng)景是下單場(chǎng)景，也就是點(diǎn)提交訂單時(shí)的操作，B場(chǎng)景是支付場(chǎng)景，就是登到支付寶里去最終付款的場(chǎng)景。

最后結(jié)果是： 在下單場(chǎng)景下，OceanBase 2.0版本比1.4版本的性能提升了63%，在支付場(chǎng)景下，提升了58%。

未來OceanBase會(huì)加強(qiáng)面向全棧的優(yōu)化，同時(shí)會(huì)對(duì)工作負(fù)載進(jìn)行優(yōu)化，也會(huì)有面向新硬件方面的優(yōu)化工作。

OceanBase會(huì)持續(xù)進(jìn)行性能優(yōu)化的工作，目的是持續(xù)為用戶提供具有最高極限性能以及最好性價(jià)比的產(chǎn)品。這是OceanBase所一直秉承的理念。