效能躍升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所一直秉承的理念。