螞蟻金服近期開展的 「共戰‘疫情’,技術破局」數字課堂線上直播系列演講咱們將整理併發布在 「螞蟻金服科技」 微信公衆號上,歡迎關注。
今天將全面解讀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進程,它們組成了一個集羣。
那麼接下來咱們就看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。
PPT下載:https://files.alicdn.com/tpsservice/e099a7f95bca0aa3f6707c79f782093d.pdf