站長資訊網螞蟻金服近期開展的 “共戰‘疫情’，技術破局”數字課堂線上直播系列演講我們將整理并發布在 “螞蟻金服科技” 公眾號上，歡迎關注。
今天將全面解讀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。
特別提醒：本網內容轉載自其他媒體，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。
