性能躍升50%！解密自主研發的金融級分佈式關係數據庫OceanBase 2.0

小螞蟻說：

相信你們對螞蟻金服自主研發的金融級分佈式關係數據庫OceanBase的故事再也不陌生了。在剛剛過去的2018年天貓雙11中，成交額2135億再次創造了新紀錄，而支撐今年雙11的支付寶核心鏈路就是OceanBase
2.0版本。

本文小螞蟻將爲你們詳述OceanBase如何在去年一樣機器數量的狀況下，來支撐今年雙11的流量洪峯，一塊兒來學習一下吧~

本文做者爲螞蟻金服OceanBase團隊資深技術專家顏然，他也是OceanBase初創成員之一，目前負責事務引擎以及性能優化方面的研發工做。（文末有彩蛋）

OceanBase：在普通硬件上提供極限性能的數據庫服務

OceanBase是徹底自主研發的金融級分佈式關係數據庫，從架構上能夠經過擴展機器來解決集羣服務能力的擴展需求。

OceanBase採用多副本複製的方案解決了可靠性和可用性的需求，並且構建在普通PC服務器上，不依賴於高端引擎。

咱們的目標是在普通硬件上提供極限性能的數據庫服務。那麼，OceanBase的存儲引擎有什麼特色呢？

OceanBase的存儲引擎相似於LSMTree，全部新增的修改都會先記錄在Memtable中，這些數據的變動並不會實時寫到磁盤上，而會在後臺按期寫到硬盤上。

不論是磁盤仍是SSD，當有大量寫入的時候，它的讀取性能都會受到很大影響。從一開始OceanBase的架構就是爲了適應這種硬件的特性，因此沒有隨機寫的操做，對於SSD和磁盤都很友好，能夠將硬盤的吞吐量優點發揮出來，把硬件資源最好的性能壓榨出來。

OceanBase從0.x版本到1.x版本，再到如今的2.0版本，一直在推進的一件事就是把硬件的性能作到極致，但願在一樣的硬件條件下能給業務帶來更多性能的空間。OceanBase的目標一直是有極致性能而且性價比最好的數據庫。

OceanBase的性能目標：極致壓榨硬件性能

從用戶使用角度來看，數據庫有兩個重要的指標，延遲（Latency）和吞吐量（Throughput）。這是兩個很是不同的指標。

根據排隊論模型，這二者之間的關係如上圖所示：隨着吞吐量增長，延遲近似指數倍增加。

當總體系統的性能不是特別高的時候，能夠保持延遲的穩定性。當系統性能壓力很高的狀況下，延遲會增長，咱們要作的事情就是要在一個合理的延遲狀況下，讓吞吐量能夠儘量大。換句話說，其實就是把一個請求要作的事情儘量的減小，而後讓單位時間內能作的請求儘量的多。性能優化的最終目標就是在延遲能夠接受的場景下，儘量提升系統的吞吐量。

性能優化工做

在剛剛過去的2018年天貓雙11中，成交額2135億再次創造了新紀錄。那麼在螞蟻金服/支付寶這樣的場景下，支付的壓力會所有落在OceanBase 2.0版本上。在2.0版本里咱們作了一個很重要的事情來進一步壓榨硬件的性能——也就是在去年一樣機器數量的狀況下，來支撐今年的流量洪峯。

在一樣的硬件環境，一樣的機器規模數這些條件下，經過升級的服務器版本以及服務器的部署方式，來提供今年雙11在0:00:00洪峯到來時的抗壓能力。 雙11的支付壓力是典型的OLTP模型，有大量的增刪改查操做。OceanBase的存儲模型決定了操做主要在內存中進行，因此在滿負荷運轉下CPU是主要瓶頸。

CPU的資源如何壓榨到極致，其實主要包含兩方面的工做：

一是優化語句執行消耗指令數（Instructions /SQL），即每一個請求須要執行的指令數，指令越少越好；

二是優化系統執行指令的效率（Cycles /Instruction），能夠用CPI（Cyclesper Instruction）表示。

系統性能由每一行代碼決定

任何一段代碼均可能致使bug，任何一行代碼也都有性能優化的空間。針對不一樣的場景，咱們須要深刻到每行代碼裏去看能夠作什麼樣的優化。

OceanBase 2.0版本進行了深度的優化得到了很好的性能提高。上圖所列的只是其中一部分優化工做。性能優化是一個事無鉅細的工做，有點相似於測試工做，本質上每一行代碼都會影響系統的性能。

優化CPU開銷

Commit異步化

在OceanBase已有的模型裏，網絡模塊有單獨的線程池負責和客戶端通訊，接受用戶請求和返回請求結果。接收到的請求會發在任務隊列中由工做線程處理。

相比較於每個用戶的鏈接使用一個獨立的線程服務的模型，OceanBase的模型能夠大大減小上下文切換的次數。

對於SQL語句的執行，這已是一個很好的模型了。可是對於事務的提交操做，須要將日誌在本地持久化和發送到其餘副本持久化，提交操做又會使得工做線程出現等待的狀況。

Commit異步化是在事務提交日誌後再也不等待日誌持久化，工做線程能夠直接去隊列中取下一個任務執行。等日誌持久化完成後，經過回調的方式出發事務提交完成的操做和給用戶發送請求的結果。

優化系統擴展性

擴展性問題

咱們作了不少事情讓系統少作無謂的事情，多作有用的事情，也就是增長CPU作有效工做的時間佔比。

機器的CPU核數愈來愈多，從原來的幾十個核和如今的一百多個核，在英特爾的PC Server上都是很常見的場景。系統在服務器上運行，多核CPU的擴展性是一個很重要的方面。這裏以計數器場景舉例，單個線程和多個線程一塊兒操做同一個計數器，後者由於多個核之間競爭同一個內存單元，性能會降低幾百倍。其實有時候人多不必定力量大，人多也有可能致使你們一塊兒搶賽道。

在系統中也大量存在相似的競爭場景，內存分配器是一個常見場景。多個線程在操做同一個memtable時，會從連續的內存塊中分配內存，分配內存的操做就好似計數器的競爭。因此，要把memtable的內存分配操做作成分區的形式，減小多個核之間的競爭。

說到底性能優化其實就是在優化系統的各個細節，每一個細節都要作到極致，最終性能才能壓榨到最好的那個點，才能把硬件自己的性能發揮到最好。

性能無止境

咱們能夠看到，藍色塊表明的是OceanBase 1.4版本，也就是咱們如今使用的主力版本，綠色塊表明了OceanBase 2.0版本。A場景是下單場景，也就是點提交訂單時的操做，B場景是支付場景，就是登到支付寶裏去最終付款的場景。

最後結果是：在下單場景下，OceanBase 2.0版本比1.4版本的性能提高了63%，在支付場景下，提高了58%。

OceanBase的將來

將來OceanBase會增強面向全棧的優化，同時會對工做負載進行優化，也會有面向新硬件方面的優化工做。

OceanBase會持續進行性能優化的工做，目的是持續爲用戶提供具備最高極限性能以及最好性價比的產品。這是OceanBase所一直秉承的理念。