100％自主知識產權！螞蟻金服自研資料庫OceanBase的設計與實踐哲學
作者 | 隗華
編輯 | 薛梁
本文整理自 2018 年 Archsummit 北京站螞蟻金服 OceanBase 團隊高級技術專家隗華（花名：風羿）的演講，本文將帶讀者深入了解 OceanBase 應對業務挑戰時在架構上的演進和思考。
1
寫在前面
OceanBase 自 2010 年開始立項，到現在已經走過了大約八年多的時間。這八年風風雨雨，幾度生死。我們一直秉承著這樣一個理念：產品和技術最終是為了解決業務的實際問題，幫助業務持續成長而存在的。
關於 OceanBase
關於 OceanBase 資料庫，我會從以下四個斷言開始介紹：
100% 自主知識產權的國產資料庫：這意味著 OceanBase 資料庫不基於任何開源資料庫，比如 MySQL。我們的百萬級的代碼都是整個團隊一行一行地積累起來的，所以 OceanBase 完全是一個擁有自主知識產權的資料庫；
商業資料庫：OceanBase 在早期 0.4 版本的時候曾經開源過，從 0.5 版本後，OceanBase 開始在支付寶的核心鏈路上線以後，整個團隊調整了產品的整體定位，逐漸向商業資料庫的方向發展。在這樣一個大背景下，在可預期的未來很長的一段時間裡，OceanBase 還會是一個閉源的資料庫；
通用關係型資料庫：OceanBase 是滿足 ACID 特性的通用關係型資料庫；
原生分散式資料庫：OceanBase 也可以被歸到 NewSQL 資料庫里，OceanBase 一直堅持的一點就是：在資料庫層能夠解決的事就全都放在資料庫里去解決，所以我們支持兩階段提交協議、全局索引和全局一致性等。
OceanBase 項目從 2010 年開始啟動，到現在為止走過了八年。2014 年，OceanBase 在內部開始承接支付寶的核心業務。截止到今天，幾乎所有的支付寶業務，不管是核心鏈路和非核心鏈路，都是跑在 OceanBase 上。2017 年底，OceanBase 開始走向外部，正式對外商用，到現在已經服務了數十個客戶，持續幫助客戶打造互聯網金融的核心。
OceanBase 目前已經發布到了 2.0 版本，而且這個版本已經經歷了 2018 年雙 11 的洗禮，後面我們也會把 OceanBase 2.0 版本推向外部，來幫助更多的外部客戶解決他們的實際問題。
2
OceanBase 架構介紹
OceanBase 本身是一個分散式的集群，通常情況下是多副本的存儲。所以一般會分為三個子集群，每一個子集群叫做一個 zone。一個 zone 里有多個節點和伺服器組成，我們管它叫 OBServer。對於每一個分區，在整個集群內它都有三個副本。
Paxos 協議介紹
另外值得一提的是，OceanBase 支持的 Paxos 協議。Paxos 協議本身相對複雜，但是其哲學思想是非常簡單的，就是一個多數派投票協議。比如一個事情，A 認為成功，B 認為成功 ，C 認為不成功，根據多數派協議認定這個事情最後是成功的。那麼具體到這裡，這三個分區的一主兩備，就形成了 Paxos 協議的成員組。
微觀來看，這是實現資料庫高可用和強一致性的一個基礎。簡單的描述一下：
每個分區在集群里的數據實際有三份，即三副本。三副本之間的數據同步靠 Leader 副本的事務日誌同步到其他 Follower 副本中。Paxos 協議會保障這個事務日誌傳輸的可靠性（事務日誌在一半以上的成員會落盤，剩餘成員最終也會落盤），同時還有以分區為粒度的選舉機制，保障 Leader 副本不可用的時候，能快速從現有兩個 Follower 副本里選舉出新的 Leader 副本，並且數據絕對不丟。
那麼通過這種方式，在任何一個時間點數據在三個 zone 當中，必然是有兩份完全一致的數據，而且是強一致的，這個是 OceanBase 實現一致性的基礎。
同時通過這種方式，也可以實現資料庫的高可用。現在有三個副本，其中有兩個是完整數據的。如果宕掉一個副本的話，還剩下兩個，那麼其實對整個集群對外服務是完全不受任何影響的。
這裡就體現了故障切換時的兩個重要指標：RPO=0，RTO
OBProxy 介紹
OceanBase 是一個集群資料庫，應用又該如何訪問這個資料庫？
每一個 OBServer 都提供直連的功能，那麼對於應用來說，當然第一個做法可以直接連裡面任意的一個 OBServer，但連了之後有相當大的概率會面對你所連的 OBServer 上並沒有要訪問的數據。但是 OBServer 本身提供這樣一種能力：可以通過解析 SQL 語句，跟內部的位置信息進行比對，然後知道你要訪問的數據在哪個 OBServer 之上，然後再做一次轉發。
但是這樣就存在一個問題：首先你要做一個 SQL 的解析，SQL 解析本身會耗去一段時間；然後解析完了之後，如果發現數據沒在這裡的話，你還要再做一次轉發，這個轉發又會耗去一部分時間，那麼對於 SQL 的響應時間是一個很大的挑戰。
所以在這個基礎上我們做了一款產品叫做 OBProxy，OBProxy 簡單理解就是一個輕量級的 SQL 解析器。
那麼當 SQL 來的時候，通過解析器可以做一個輕量的解析，大體看一下數據的位置。每一個 OBProxy 會維護一個本地的 location cache，然後做一個比對，知道數據在哪，然後直接做轉發，把它發到對應的 OBServer 節點上去執行。執行完之後，結果通過 OBProxy 再返回給這個應用。
存儲引擎介紹
那麼最後簡單給大家介紹一下 OceanBase 的存儲引擎，基於 LSM-Tree 的架構。增刪改的數據其實都是在內存里。OceanBase 跟傳統資料庫不太一樣的地方，就是傳統資料庫中當一個數據修改來的時候，要實時去修改存儲，但是在這種架構下，增刪改的數據就是增量數據，它始終是放在內存里的。
那麼這個架構帶來的一個好處就是增刪改相對來說會比較快。這個是肯定的，因為全部都在內存當中進行。
但是有一個架構上的缺點。在讀的時候，可能你的數據在內存和磁碟上同時都有。那麼我們的做法是說我們接受這個事實，然後在裡面做一些優化。
如上圖所示的資料庫中經常提到的 「Row Cache」、「Block Cache」 還有 「Bloom Filter Cache」 等，熱數據會緩存起來，大部分單行操作只需要一次緩存查找，沒有額外開銷。那麼相對來說性能能夠達到一個比較好的狀態。
我們線上的機器一般內存都比較大，一般都在 512G，這些數據是不會往磁碟里去刷。當然，內存當中的增量數據到達一定的條件後，即便有 512G 也總會爆的，最後總得把它寫回到磁碟上來，我們管這個過程叫合併。那麼合併的過程會產生大量的 IO，其實對性能會有一定的影響，影響可能在 10% 左右。
當然這個合併其實也會帶來一些額外的好處，比如說數據壓縮。一般來說資料庫在做數據壓縮都是及時的；但是在 OceanBase 里，可以選擇在合併的時候做一個集中的壓縮。
現在大家知道，其實資料庫我們廣泛的使用 SSD，隨機讀寫型的 SSD 相當的貴。但是在 OceanBase 里，因為我們有這樣的一個操作：寫操作都在內存里進行，寫磁碟都是在合併的時候，所以能夠實現順序的寫，最終使得硬體的成本大幅度的降低。
3
OceanBase 架構演進
OceanBase 是從 2017 年的時候開始走向外部，在這中間經歷過很多艱難和挑戰，可能是原來在淘寶和支付寶體系中根本不可能碰到的一些挑戰。比如：
如何在業務高峰平滑擴容，高峰後如何縮容，甚至對業務無感知；
如何去 O，如何保證風險可控地去 O；
如何解決多活和異地容災；
如何備份分散式資料庫，如何恢復到一個全局一致的時間點；
如何規避分散式資料庫的種種限制，如分區鍵和主鍵的綁定關係；
如何合理部署分散式資料庫，與現有雲平台如何整合；
如何解決業務數據量膨脹之後的冷熱數據問題。
4
通過副本類型變更支持彈性大促
首先介紹一下 OceanBase 的副本類型：
5
支付寶的彈性大促
上圖就是支付寶彈性大促的簡單示意圖。在支付寶，我們會根據 UserID 做單元化。那麼對於 OceanBase 來說，其實就是上圖可以看見的四個 UserID 的數據，都是由機房 4、機房 6 和機房 8 組成的 OB 集群來提供的數據能力。上層的應用肯定會有一些租借的機房，就是如上圖所示的 2、3、5、7 這些所謂的雲機房。那當應用發布過去以後，我們要做的就是把 OB 相關的數據也挪到相應的雲機房去，最終實現從原來 1 個機房服務 4 個 UserID 到最終每個機房只服務 1 個 UserID，達到一個擴容的效果。
那麼具體是怎麼做的？
第一步，在異地的機房裡部署三個只讀副本，它們不參與 Paxos 協議的投票，但是會不斷地從主從副本里把數據傳過去。只讀副本本質上對集群本身是完全沒有影響的，包括應用也是完全無感知的。
接下來要做的一個事情就是把其中的兩個只讀副本 D 和 E 把它通過副本變更變成一個從副本 Follower。那麼大家可以看到現在的 OB 集群，它是由一個三副本的狀態變成了五副本狀態。
那麼同樣的，對應用來說，它訪問集群是在機房 4，所以是完全沒有感知的。然後接下來要做的一個事情，就是我們又把五副本降為三副本，把原來的兩個同步變成了只讀副本。
接下來一步，這一步其實對業務相對來說是敏感的。原來的機房 4 的 A 做了一個切除的操作，也就是把原來的 Leader 副本變成了 Follower 副本，然後把它切到了機房 3。那麼這個時候我們形成了新的三副本的集群。
再往後走，我們又做了一個副本變更的操作，把原來的從副本 A 變成了一個只讀副本，然後把原來的最後一個只讀副本 F 變成了一個從副本。
那麼大家可以看到這個時候，UserID 1 服務的資料庫集群已經不在原來的機房 4 了，最後我們把這些只讀副本全部下掉了，最後就完成了整個支持彈性大促的過程。那麼大促完之後，我們基本上也是一個反向操作，可以把它恢復成原狀。
6
通過熱備庫解決異地容災
剛才提到，阿里內部硬體條件是比較好的。當我們在走向外部的時候，突然發現很多客戶其實是沒有三機房，甚至它的網路條件也很差。
可能會面臨最明顯的兩個問題：
1）如果只有兩機房如何部署三副本？一般來說一個機房部署兩個副本，一個機房部署一個副本。這個時候有一個問題：如果放兩個副本的機房宕掉了，你就只剩下放一個副本的機房。那就意味著丟數據。
2）這裡基於一個硬體不穩定的假設，當你只剩下一個副本的時候，我們可以利用一些手段重新啟動，但是當再一次發生硬體的故障的時候，那麼這個數據就會完全的丟失。
所以我們在這個基礎上，做了這麼一個方案：就是在兩個機房同時也是兩座城市，分別放上，如上圖所示在北京放上 4 個副本，在蘇州放 1 個副本，然後形成一個 OB 的業務集群。那麼平時客戶的應用在北京的集群這邊進行訪問。然後在蘇州，我們其實還有三個備份副本。
如果北京的 1 個機房發生災難，那麼五個副本中還剩下三個，集群還是可以正常工作。
如果北京的兩個機房都發生災難，垮掉了，那麼我們會做一個接管的操作，把這三個備份副本升級成一個全功能副本構成一個新的集群，然後為業務提供服務。
7
OMS 遷移服務：向分散式架構升級的直接路徑
其實我們原來積累了很多去 O 的經驗，但是在淘寶和支付寶，去 O 很多時候是通過應用層的改造去實現。對於客戶來說，這件事就變得很複雜，不少客戶應用層的代碼不夠完善。
只能完全以 Oracle 的這種方式去解決他的問題，所以我們打造了這款一站式數據遷移解決方案—— OceanBase 遷移服務（簡稱 OMS ），從評估兼容性，到驗證 SQL，最後等到所有的校驗都完成以後可以一鍵完成切換。
如果 Oracle、MySQL 等其他的一些資料庫往 OB 上遷，那麼最後的關鍵一步是什麼呢？
最關鍵的一點，就是 OMS 有隨時回滾的能力，而且回滾是無損的。比如說從 Oracle 把數據遷到 OB，在切應用的那一瞬間，其實原來的 Oracle 在繼續跑，然後把新的數據同步的鏈路做一個反向——從 OB 到 Oracle，也就是說新的系統如果跑在 OB 上，新產生的數據它會同樣回到原來的 Oracle 資料庫中去。
通過 OMS 就可以輕鬆完成從傳統商業資料庫到分散式資料庫的完整遷移，這是企業穩妥創新的基石。
8
下一代 OceanBase
最後簡單展望一下下一代的 OceanBase，其實所謂的下一代也就是可能一年半之後就能達到的一個狀態。
第一點是 Oracle 兼容性，我們始終致力於 Oracle 兼容性方面的工作。那麼現在我們的產品能達到 20~30% 的 Oracle 兼容性，當然這其中包含有幾個層次的東西。首先最簡單的語法兼容，那麼第二個是功能和性能的兼容，第三個由於 OceanBase 本身是一個分散式資料庫，Oracle 它是一個集中式資料庫，那麼對於客戶來說，還要屏蔽掉架構上的差異，讓客戶無感知。大體上兼容可能分為這麼幾個層次，那麼我們會逐步深入往下做。
第二點是計算存儲分離，我前面其實也講過，OceanBase 是一個計算和存儲融合的這麼一個架構。這個架構它相對來說比較簡單，但是存在一個問題，就是你的業務是計算先達到瓶頸的，還是存儲先達到瓶頸的。這兩種情況往往是不一樣的，往往時間點也是不一樣的。在架構里就存在一定的浪費。如果說計算不夠，也是加一台機器；存儲不夠，還是加一台機器。所以本身就對成本是一種浪費，所以我們現在致力於更深入做計算和存儲的分離。
那麼最後還有一點，就是我們做的 HTAP。現在的場景更多是 TP 類的場景，也就是聯機交易。當然其實我們也支持很複雜的查詢，我們在阿里內部也有一些像廣告類的偏查詢類的業務。我們在持續的打造 AP 的能力，包括資源的 SQL 執行器的一些並行計算框架，力爭在不久的將來能夠更好的支持混合型的負載。
OceanBase 未來會持續打磨自身，通過不斷迭代的產品幫助更多企業、更多業務穩妥創新，持續成長。
作者介紹
隗華，螞蟻金服基礎數據部高級技術專家，碩士畢業於北京大學計算機研究所。2017 年加入螞蟻金服 OceanBase 團隊，是 OceanBase 產品和外部業務專家服務的負責人。在加入阿里之前，在 IBM 和百度雲有多年的資料庫相關經驗。
不同的業務對存儲的要求不同，存儲產品也會隨著技術的更新而改變，例如 Alibaba 自研的分散式緩存系統 Tair，歷年來承擔著雙 11 購物節及各大型活動。7 月深圳 ArchSummit 架構師峰會上，邀請了 Alibaba 存儲技術事業部高級技術專家王若老師來分享新一代存儲的架構設計思路。
TAG:InfoQ |