OB君：本文是 “OceanBase 2.0 技術解析系列” 的終篇。在前面的系列文章中，我們從可運維性、分布式架構、資料可用性及相容性四個方面對OceanBase 2.0的産品新特性及其背後的技術原理進行了系統性的深入解析。
今天的終篇我們來聊聊最重要的OceanBase 2.0在性能優化方面所展開的工作，以及OceanBase是如何實作極緻性能的。本文整理自10月27日OceanBase TechTalk北京站活動中顔然的演講《OceanBase 2.0的性能突破》。
Tips：你可以關注"OceanBase"公衆号，回複“1027”一鍵下載下傳PPT
今天的内容主要分為以下幾個部分：首先為大家簡單介紹一下OceanBase的架構和存儲引擎，以及OceanBase的優化目标和圍繞目标所展開的工作，最後還将分享一下我們未來在性能優化方面的規劃。
OceanBase介紹
OceanBase是完全自主研發的金融級分布式關系資料庫，從架構上可以通過擴充機器來解決叢集服務能力的擴充需求。
OceanBase采用多副本複制的方案解決了可靠性和可用性的需求，而且建構在普通PC伺服器上，不依賴于高端引擎。
我們的目标是在普通硬體上提供極限性能的資料庫服務。那麼，OceanBase的存儲引擎有什麼特點呢？
OceanBase的存儲引擎類似于LSM Tree，所有新增的修改都會先記錄在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（Cycles per 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所一直秉承的理念。