今天將全面解讀OceanBase 2.2版本的核心特性，解析在異地容災多活、線上資料遷移等場景下OceanBase的完整解決方案，以下為OceanBase團隊的慶濤老師演講整理全文：
大家下午好。我是來自螞蟻金服OceanBase團隊的慶濤，很榮幸能在雲棲社群直播平臺為大家分享OceanBase資料庫的相關知識。OceanBase官網最近釋出了2.2版本的安裝包，大家可以免費下載獲取。安裝檔案裡面包含了兩個重要產品，一個是OCP（OceanBase Cloud Platform）和OceanBase 2.2版本，其中OCP是OceanBase的自動化運維平臺，這次分享打算分兩期給大家介紹OCP和OceanBase 2.2的功能，以及OceanBase 2.2的運維和開發。
首先跟大家分享一下OceanBase產品的定位和發展歷史。
一個常見的問題：很多人會問OceanBase資料庫到底是什麼？首先OceanBase和Oracle / MySQL一樣，它是一款關係型資料庫，但是跟Oracle和MySQL不同的是，它是分散式架構的關係型資料庫。而且它是一款原生的分散式資料庫，不是分庫分表中介軟體架構的資料庫。OceanBase資料庫由阿里巴巴和螞蟻金服完全自主研發，不依賴於任何開源專案。目前OceanBase的定位是一款商業資料庫，主要用於替換Oracle和MySQL，在部分場景下可以替換DB2資料庫。
下面為大家簡單介紹一下OceanBase的發展歷史。現在OceanBase已經有9年多的歷史，我們的第一個業務是淘寶收藏夾，業務的特點是在上百億的大表之間做關聯查詢。現在大家開啟手機淘寶，這個業務其實依然是跑在OceanBase資料庫之上。OceanBase的版本分為三個階段，其中從0.4版本開始就在支付寶承擔核心交易業務去O以及在網商銀行承擔全部的核心資料庫。1.0版本後，OceanBase架構完全重構，相容MySQL 5.6的SQL語法，從1.4版本開始逐步走向商用，第一家使用OceanBase的客戶是南京銀行。2018年9月，OceanBase 釋出了2.0版本，OceanBase開始相容Oracle的SQL語法，現在內部版本已經到了2.2.3。目前我們可以做到相容70%左右的Oracle常用語法。
接下來為大家介紹OceanBase的幾個重要的外部客戶，目前網商銀行全部的核心業務資料都在OceanBase上，南京銀行的網際網路核心業務，參照網商銀行的架構搭建，也使用了OceanBase資料庫。全國各地有越來越多的城商行、農商行、以及一些網際網路保險、證券公司的業務，目前也開始在OceanBase上部署。
OceanBase能在金融行業紮根，除了有支付寶強大的業務場景背書外，還離不開OceanBase最核心的六大產品能力：
第一就是高可用。OceanBase的架構設計天然就是為故障容災而設計的，它的資料至少有三副本，任何時候機器故障，只可能會出現區域性的資料訪問中斷，並且會很快地自動恢復，恢復時還可以保證資料絕對不會丟失。這就是我們通常說的 RTO約等於30秒，然後RPO=0。這裡30秒是包括故障探測時間。
第二個能力就是分散式架構，OceanBase資料庫可以線上擴容、縮容、遷移、以及做負載均衡，並且整個叢集可以異地部署，跨城市部署。成熟的方案有兩地三中心和三地五中心。
第三個能力就是相容Oracle和MySQL的常用語法。我們現在重點是相容Oracle的語法。
第四個能力就是高效能，2017年，OceanBase支撐了支付寶雙11大促活動，交易峰值達到每秒鐘25.6萬筆。2019年，OceanBase得到了國外權威機構TPC-C的認證，測試結果達到6088萬tpmC，榮登效能榜首，是 Oracle結果的兩倍。
第五個能力是低成本。OceanBase基於普通的PC伺服器，只需要SSD盤、萬兆網路，不需要小機，儲存，還有光纖網路。
第六個能力就是多租戶的能力。OceanBase使用的時候很像雲資料庫，但是它跟雲沒有必然的關係。在OceanBase叢集裡面，我們可以按需分配例項，還可以線上的資源擴容或者縮容。
那麼接下來我來帶大家詳細了解一下OceanBase 2.2版本的核心功能以及背後的原理。
首先是叢集，OceanBase叢集架構至少包括三臺機器，上圖裡例項是九臺機器，機器會分為三個區域存放，每個區域我們稱為一個zone，zone可以是小到一個機櫃，機房，大到一個數據中心。三個資料中心的機器，整體上我們是做成一個OceanBase叢集，每個機器都是普通的X86伺服器，普通的SSD，萬兆網絡卡彼此互通。
我們會在每個機器上面執行一個OceanBase的資料庫軟體，它是一個單程序程式，叫OBServer，每個機器上的OBServer程序的作用基本上是一樣的，都包含兩個模組，一個是SQL引擎、一個是儲存引擎。整個叢集裡面會有一臺機器比較特別，它會有一個RootService，我們稱為總控服務。所以從這個架構圖上來看，當9臺機器全部運行了OBServer程序以後，在我們眼裡它就是9個OBServer程序，它們組成了一個叢集。
OBServer程序有一個特殊的能力，程序起來之後，它會把主機的絕大部分的CPU記憶體和磁碟空間資源佔為己有。所以9個機器啟動了OBServer程序之後，在我們的眼裡的話就變成了9個資源單位，每個有30個CPU，200G記憶體、4T空間。它們組成叢集就形成了一個超大的資源池子，270個CPU、1800G記憶體、36T空間。實際上這是所有的分散式資料庫都要具備的基本能力，就是把各個機器的能力、資源聚合在一起。
那麼接下來我們就看OceanBase叢集的資源池，這麼大一個資源池它怎麼使用？這就要提到OceanBase強大的多租戶能力。首先OceanBase會有一個內部租戶，這個租戶，也就是我們說的內部例項，主要是用於管理用的，它會佔用少量的資源。15個CPU，60G記憶體，那麼剩下的這些大部分資源就是未分配的，是留給業務用的。這時候我們來了兩個業務，每個業務它會說我需要多少資源，那麼在OceanBase裡面就會劃分出一塊資源給業務使用，沒有分完的，就留待給其他的業務使用。
從這裡的設計可以看出，當我們的業務方需要一個數據庫的時候，我們的運維人員在一分鐘以內就可以把資料庫建立好，運維的效率大大提升。
接下來再來看一下OceanBase裡面資料分佈的特點。首先OceanBase裡資料的最小單位，不是表而是分割槽，但分割槽跟表是有關係的，我們說一個普通的表就是一個分割槽，像這裡的t1表，表明它就是一個分割槽，我們給它編個號叫0號分割槽，所以這裡寫t1(p0)就表示 t1表的分割槽，但是一個分割槽表會有多個分割槽，像t3表、t4表的話，它就是分割槽表有0號分割槽、1號分割槽、2號分割槽，有三個分割槽。這些分割槽是分佈在OceanBase叢集任意的機器裡面，沒有固定的位置，這是第一個特點。
第二個特點是每個分割槽會有三個副本，副本就是指一模一樣的內容，像 t1(p0)，它也會有另外兩個t1(p0)，三個副本在角色上面會有所區分，我們通過顏色來區分，比如綠色的是主副本，我們也稱為leader副本。黃色的是備副本又叫follower副本。預設情況下只有主副本提供讀寫服務，follower副本不提供讀寫服務，並且每個分割槽的三個副本一定是分佈在三個zone裡面的，我們橫向看是三個zone。在OceanBase裡有一個反向代理軟體叫OBProxy，它的作用主要就是接受應用的SQL請求。收到SQL之後會把請求轉發到主副本所在的節點上面，OBProxy後面還會詳細的介紹。
我們來看另外一個問題，三副本的內容是怎麼保持同步的？比如說t1(p0)有三個副本，預設只有主副本提供讀寫。它們之間的同步是靠主副本上面的事務日誌，也就是clog。當主副本上一個事務要提交的時候，它會把clog同時發給兩個備副本。然後三個副本會把日誌持久化到磁碟上，當三個成員裡面，絕大多數成員把這個事務日誌寫成功之後，主副本上的事務就可以提交了。這裡協議使用了Paxos協議。
除了保持資料同步以外，當主副本出現故障時，OceanBase會自動的從兩個備副本里選出一個新的主副本出來，並且會保證新選出來的主副本擁有全部的事務日誌，所以資料是不會丟的。OceanBase的故障切換的力度很細，它是分割槽級別的，所以我們不會說某一臺機器是主某一臺機器是備，從這個圖裡面我們可以看出來有5臺機器有主副本，凡是有主副本的機器都可以提供服務。當你的業務表很多的時候，每臺機器上實際上都可以有主副本，所以OceanBase的機器是沒有主備概念的。
接下來我們詳細的講解OBProxy的功能。OBProxy的功能其實說起來也很簡單，它就是隻做SQL路由，不參與運算。當收到業務的SQL請求，分析出裡面要訪問的表，然後找到表對應的分割槽的主副本在哪個機器上面，就把它轉發過去，取出資料之後原路返回。對於使用者來說，OBProxy就是OceanBase資料庫的一個代理，所以OBProxy的可用性非常重要。通常情況下我們會部署多個OBProxy，然後把它們掛在使用者已有的一個負載均衡裝置上面，比如說F5上面，然後F5提供一個VIP給業務用，但F5的高可用是靠自身的備機去提供。
這裡順帶提一下，除了OBProxy有路由功能以外，OBServer自身也是有路由功能的。
接下來我們來看一下OceanBase的SQL相容性。
前面說OceanBase支援多租戶，它可以相容MySQL或者Oracle，實際上只能2選1不能同時相容。下圖左側是MySQL常用的SQL功能，右側是目前實現的Oracle常用的SQL功能。就Oracle功能這一塊，現在是重點發展的方向。
資料型別的話，我們已經實現了75%的型別和86%的函式。儲存過程也支援了不少功能，有些場景下業務客戶的儲存過程是可以平遷到OceanBase上的。在事務方面，OceanBase支援兩種事務隔離級別，一個是讀已提交，還有序列化隔離級別，這點是跟Oracle一致的。
OceanBase支援跨節點的分散式事務，內部原理是兩階段提交，強一致的，並且這個事務對業務是透明的。使用的時候，業務只要稍微注意一下額，這個事務一定要及時提交，以避免長事務在OceanBase裡會超時報錯。此外，OceanBase還支援自治事務。
下面為大家介紹OceanBase相關的解決方案。在OceanBase的周邊生態產品中，除了OceanBase叢集外，我們還開發了一款OceanBase運維平臺——OCP（OceanBase Cloud Platform），這款產品的目標就是讓運維人員絕大部分的工作都可以通過運維平臺來自動化完成。
第二個產品是OceanBase開發者中心——ODC（OceanBase Developer Center），面向開發人員，目標是讓開發人員能通過這個平臺去連線資料庫，而不用直連資料庫，這樣我們可以控制權限和審計功能。
第三個就是OceanBase的遷移服務——OMS（OceanBase Migration Service），我們重點看一下OceanBase的遷移服務。為大家分享一個客戶案例，某銀行有一個Oracle業務，有一個MySQL業務，我們現在需要把它遷移到OceanBase上來。剛開始的時候客戶應用是讀寫Oracle和MySQL，然後我們部署OMS之後，就把Oracle和MySQL的資料分別同步到OceanBase的Oracle租戶和MySQL租戶。這個時候業務是不停的，這個同步是實時同步，它會同步增量。當增量追上的時候，我們再尋找一個業務低峰期的時候，讓業務短暫的停寫原來的資料庫，這個時候OMS可以對兩邊的資料做一個全量的校驗，確保兩邊資料是一致的，然後再做決定，即切換。所謂的切換就是OMS把資料同步的方向給調整一下，從OceanBase同步回原來的Oracle資料庫，這時候客戶的業務再把連線指向新的OceanBase資料庫，那麼這樣的一個切換過程就完成了。這裡我們會把OB的資料同步回Oracle，這個是為了方便回滾，一旦客戶決定再切換回去的時候，我們只需要把這些操作反過來做一遍就可以。同樣的在回切的時候，我們依然要兩邊做資料校驗，校驗一致之後，我們再把同步方向返回來應用，把連線改回去就可以了。
OceanBase的容災方案常用的就是兩地三中心。兩地三中心中整個叢集是三副本架構，分佈在三個機房，其中同城兩機房，延時是2毫秒，異地機房延時是7毫秒。任何一個機器或者機房故障的話，資料庫的服務都可以很快的恢復，並且保證不丟資料。當然有個缺點，故障之後寫效能會下降一點點，如果應用不能承受效能下降的話，我們通常會做5副本，也就是三地五中心。
最後我們來總結一下OceanBase的幾個核心關鍵字，低成本、高可用、可擴充套件、高效能的分散式關係型資料庫，同時它又像雲資料庫一樣，並且適合金融行業的異地容災和多活。OceanBase目標就是做一款分散式的Oracle。