螞蟻金服近期開展的 “共戰‘疫情’，技術破局”數字課堂線上直播系列演講我們將整理併發布在 “支付寶科技” 頭條號上，歡迎關注。
今天將全面解讀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。
閱讀更多 支付寶科技 的文章
