當前位置:
首頁 > 科技 > 螞蟻金服自研資料庫OceanBase的前世今生:從瀕臨解散到浴火重生

螞蟻金服自研資料庫OceanBase的前世今生:從瀕臨解散到浴火重生

作者 | 陽振坤

編輯 | 小智

出處 | OceanBase 公眾號

OceanBase 是螞蟻金服自研的分散式資料庫,在其 9 年的發展歷程里,從艱難上線到找不到業務場景瀕臨解散,最後在雙十一的流量考驗下浴火重生,成為螞蟻金服全部核心系統的承載資料庫。這一路走來的艱辛和故事,螞蟻金服高級研究員、OceanBase 團隊負責人陽振坤將為你娓娓道來。本文原題為《OceanBase:跨越關係資料庫的死亡之谷》。

1

資料庫:技術和市場的「死亡之谷」

資料庫在每個人的生活里無處不在,不管是通訊、交通、金融行業,抑或是每天大家都在接觸的互聯網,所有這些業務的背後都是資料庫在支撐。

螞蟻金服 OceanBase 團隊負責人陽振坤

資料庫經歷了近半個世紀的發展,在理論上很成熟,在技術應用上也已經非常成熟了。但是資料庫偏偏有一個特別高的門檻,原因是資料庫有三條特別苛刻的要求:



  1. 事務須並發處理:

    資料庫要支持事務,所有人都希望用最小的處理資源,做到最大價值的事情。所以事務持續要做大量的並發處理。


  2. 數據一條不能錯:

    一個資料庫如果數據錯了,就永遠沒有機會了。對於使用者而言,如果你會錯一條,你就有可能會錯一千、一萬條,這是沒有公司願意承擔的風險。


  3. 服務片刻不能停:

    通訊系統、列車系統,甚至飛機航行系統的背後都是資料庫在支撐,這些系統一旦啟動,一分一秒都是不能終止的。

上面提到的這三條要求,任何兩個其實都好滿足。但是大家仔細想一想,這三個要求如果要同時滿足,就會變得極其困難。

同時,資料庫又是一個巨大的市場,對國家、對整個社會都非常重要。這就導致很多國家、很多企業都想做也正在做這件事,但是結果大家都做到了同一個思路上。後來者都成了先行者的模仿者,那麼這個模仿的代價就會變得很大。

今天作為一個後來者,你再去做這麼一套資料庫系統的時候,就真的很難說清楚你與先行者相比有多大的優勢。

這也就造成了強者恆強、寡頭壟斷的局面,後來者很難居上

資料庫同樣也有開源這條路徑,比如大家都了解的 MySQL。開源是免費的,對於很多對成本敏感的公司而言開源資料庫成為了替代商業資料庫的另一種選擇。

那麼在面對資料庫的「死亡之谷」這樣的困境下,為什麼我們還去花這麼多錢,投入這麼多設備,花這麼多年時間和人力再去做一個資料庫,究竟它的意義在哪兒?它又能夠產生多大的經濟價值?

既然有了開源的資料庫,阿里巴巴和螞蟻金服還要做這麼一個商業資料庫產品,其實這裡面是有本質原因的。很多人知道阿里巴巴今天已經

全面去 IOE

:去掉了 Oracle 資料庫、IBM 小型機、 EMC 存儲。那麼很多人就在想,能不能在其他的行業,在鐵路、交通,電信、政府這些行業推而廣之,全部完成去 O 的進程呢?這個答案是否定的。

因為像阿里巴巴發展的這一套系統是基於 MySQL 的開源資料庫,跟商業資料庫在功能和性能上其實是有很大差距的。阿里巴巴當時在用它的時候,有很多事情資料庫是做不了的,那麼這些做不了的事情當時就放在應用軟體里做。所以阿里巴巴在資料庫和應用軟體上都投入了很大的技術力量。這套系統拿到外部業務去用是不能徹底解決問題的。

本質上這套系統是服務於阿里巴巴的專用系統,而不是一個通用的系統

那麼有人會問,在我的企業里,如果真的想去掉 IOE,該怎麼辦?你同樣要投入兩撥人,一撥人要去做資料庫,針對你的企業的需求來做相應的修改;還有一撥人要去做應用系統。但是問題是並不是所有的企業都像阿里巴巴有這麼多優秀的技術人員,這套東西其實很難去直接推廣應用。

所以,從一開始我們做 OceanBase 的目標就是——

我們不想只做一個專用的系統,要做就一定要做一個通用的系統

。我們希望今後 OceanBase 能夠服務於各行各業,再也不需要企業投入幾十幾百甚至幾千個人去改造、去重新做一套業務系統。

2

OceanBase 的機遇與創新

當時做 OceanBase 資料庫一個最根本性的原因就是需求的變化

。因為這麼一套基礎系統,如果背後沒有需求的變化,從 0 到 1 自己做出來基本是不可能的。

2010 年春夏之際,我來到了阿里巴巴。去了之後發現當時有兩個因素影響了阿里巴巴關係資料庫的應用。

一個因素是並發,資料庫它是按照並發量來賣錢的。說直接點,就是按照處理器來賣錢。之所以要買這麼多處理器就是因為業務有這麼大的需求。那麼傳統的業務比如商場,一個商場就那麼幾個收銀台,它是一個相對穩定而且比較小的並發量,大多數情況就是幾十幾百的並發量。

陽振坤分享經驗心得

隨著互聯網的高速發展,阿里巴巴天貓雙 11 幾乎完全改變了過去行業內相對穩定的並發量,突破了幾百萬人甚至是千萬人的同時在線購買。這個並發量跟過去的傳統業務場景相比是幾個數量級的增長,按照這個數量級去買商業資料庫,沒有一家企業買得起。

還有一個因素,當時我們叫它建站,其實就是搭建一個資料庫。過去建一個商場,建一個銀行的分店,這個周期是非常長的,有足夠的時間來規劃 IT 業務系統。互聯網業務是等不了的,就像當時 OceanBase 接的第一個業務給到我們的時間就是最多一個星期。現實是一個星期的時間根本連小型機的安裝調試都完不成。

原來的模式已經完全無法支撐互聯網快速發展的業務。所以這兩個需求的變化,是催生我們自己來做資料庫的很關鍵的因素

OceanBase 關鍵性的技術革新

當時我找了幾個同事商量這個事情,我跟大家說,我們是天時地利人和都趕上,這件事情除非是被拍死掉,否則我們是肯定要把它做成的。

這個過程真的非常艱辛,我們花了差不多五年的時間,才真正讓 OceanBase 有了關鍵的應用

過去做資料庫的公司,不管是國內還是國外,大家都是為了做資料庫而做資料庫,那麼最後結果就是所有做傳統資料庫的廠商,大家的方案都很像。

因為資料庫有很成熟的理論和工程的方法,那麼如果我們按照以往的原則做過去,結果肯定也是一樣的。所以,

其實我們走了另外一條路——做分散式

。最早做這個東西可能都不叫資料庫,它更像是一個分散式系統,但是支持了事務的特性。這條路後來被證明確實是具有特別大的價值和意義。

當時我們在做 OceanBase 的時候,首先確定了幾件事情。

第一件事就是我們要做分散式

,因為我們的業務要建站,不做分散式靠大型機和小型機是不可能做得到的。

另外一件事是成本

,什麼東西最便宜,量最大最主流的東西最便宜,它就是 PC 伺服器。小型機少則幾十萬,多則幾百萬,PC 伺服器頂多就是幾千幾萬塊的成本。

第三個要解決的就是可靠性問題

。大家對資料庫的期望是永不宕機,永遠不出問題。可是 PC 伺服器到處都有,性價比也非常好,但是不容忽視的是它的故障率高。普通 PC 伺服器它遠遠達不到資料庫所要求的年可靠性五個九的要求。對普通 PC 伺服器而言,差的可能是兩個或者三個數量級,所以我們得首先把這個問題解決掉。我們用的就是分散式的辦法來解決。

我們運用的是分散式的一致性協議,直白一點就是一個多數派的選舉和投票協議。同時,我們把修改的增量直接放在內存里,每次要查詢的時候,把內存硬碟的數據做一個 merge,那麼每天在業務相對的低谷期,再把內存中的數據整理回硬碟去。

做到了這幾件事情,這個系統就有了很好的性價比,

我們的成本比傳統的資料庫至少低一個數量級,你只需要用普通的 PC 機,不需要用昂貴的硬體設施。同時,擴展能力會也變得很好

OceanBase 的第一個業務:淘寶收藏夾

理想看起來很美好,但是現實特別骨感。這個項目剛啟動的時候,我們好不容易才找到了幾個人,人手是嚴重不足的。另外一個更大的挑戰是時間:在做 OceanBase 資料庫之前,我去找我的老闆,他說給你

兩年時間

如果能把一個資料庫做出來就可以。當時我心裡想兩年雖然對於做資料庫來說時間確實太短,但是這兩年對於那時候的我們而言已經足夠支撐起最初的想法了。

技術最終還是需要通過業務落實下去,所以我找了一批業務方,花了很長時間跟對方溝通,最後終於有一個業務願意用我們的資料庫。當時他給我的時間期限是——

兩個星期

當時我就傻了,兩個星期要做個資料庫,這可怎麼辦?後來跟業務的同學反覆討論,最後他們同意說,你們先做個 demo 出來。於是我們就花了兩個月吭哧吭哧的做了一個 demo 出來。他們看了以後覺得比較滿意,後來這個事情就一直堅持做下去了。

最後,我記得是到了第八個月的時候,系統上線了。這個業務就是現在大家都在用的——

淘寶收藏夾

,這是 OceanBase 的第一個業務。如果沒有這個業務,我們現在也活不下來。

淘寶收藏夾業務

那麼這個業務到底有什麼特殊的地方?每個人都用過淘寶收藏夾,每次你打開收藏夾的時候,資料庫在背後其實做了很多事情:我們以單個商品為例,它需要到一個叫商品庫的地方,逐條紀錄核對,看看商品有沒有下架,有沒有參與促銷,有沒有參加其他的返點活動等等。

假如你收藏了 100 多件商品,它就要進去一條條的取出來看。本質上來講,這就意味著一百多次的隨機 IO。那麼當很多人同時來看的時候,其實一個 IO 就被放大了幾百倍,這時候有多少個硬碟都不夠用。

當時他們已經用了幾十台伺服器了,按照業務的預估,第二年他們要買 400 台機器,第三年的數量都不敢想像。當時我們想了一個辦法——我們做了一個

寬表

,確切的講應該稱為

物化視圖

淘寶收藏夾的寬表

首先我們把每個用戶收藏的信息聚集起來,這樣可以減少 IO,然後把收藏的商品放在這個列表裡。但是我們怎麼避免去訪問一百多次 IO 呢?我們的辦法就是找到一個時間點,當時是設定在每天晚上凌晨兩點。在這之前,我們就把這些信息全部 merge 到硬碟,然後從兩點開始,我們把新的修改都放在內存裡面。

所以每到兩點的時候,我們把兩點之前所有的信息都合到這張表裡,那麼這張表裡的信息在兩點整的時候是準確的,這時候我們不需要去訪問商品庫。兩點之後的修改,包括商品庫的修改是在內存里進行的,這時候如果要看這些商品有哪些修改,商品只需訪問內存中的更新即可。

所以其實我們就是通過這樣一個手段,把每次收藏夾的展示,

由原來的一百多次 IO 變成了一次

。我們一下子就把淘寶收藏夾業務的整個 IO 降下來了。當時 OceanBase 確實是幫助業務實際解決了他們的問題,使得業務能夠更好的快速的發展。業務是一定要發展的,所以只有我們真正能夠解決他們的問題,我們這些做基礎系統做底層的人,才能活下去。

淘寶收藏夾架構圖

這是當時給淘寶收藏夾做的一個架構,中間是一個做修改的伺服器,所有的修改都在這一台機器上進行。旁邊的機器是基線數據,就是分片切片以後,放到周圍這一圈進行。所以當時我們就用這個看上去很簡陋的一個方案來真正解決了淘寶收藏夾的問題。

當時收藏夾用了這個方案之後,伺服器的數量從原來預計的第二年要用幾百台,最後其實只用了差不多二十幾台伺服器,就把整個問題解決掉了

OceanBase 0.3-0.4 版本:團隊面臨解散

從淘寶收藏夾項目之後,我們陸陸續續也做了不少項目,但是沒有一個項目能像淘寶收藏夾這樣對業務有明顯的價值和貢獻。

從那之後的整整兩年,我們找不到對 OceanBase 資料庫而言特別有價值的業務。那兩年對於我們而言特別特別困難,甚至整個團隊隨時面臨著解散。

2012 年底,公司把我們從淘寶調到支付寶,當時預估到支付寶在資料庫方面所面對的挑戰更大,後來證明確實如此。即使是這樣,當時仍然還處在一個非常困難的時期。到了支付寶一年多的時間,我們仍然很難找到新的業務,或者說價值比較大的業務來證明我們的價值。

OceanBase 0.5 版本:成功抗住 10% 流量

2013 年的夏天,支付寶希望全面去掉 IOE——去掉 IBM 的小型機,Oracle 的資料庫和 EMC 的存儲。當時面臨了一個問題,就是去掉之後是可以用 MySQL 來代替 Oracle,但是 MySQL 的主備鏡像其實是做不到主備完全一致的。

這個時候我們意識到:OceanBase 的機會來了

。因為我們可以通過分散式的選舉跟投票來做,哪怕硬體本身不可靠,我們也能保證數據的不丟失。傳統資料庫本質上是藉助硬體的可靠性,也就是硬體需要達到五個九的可靠性來實現高可用的。就算出了故障,它的數據也能救得回來。但是這種手段需要非常高的成本,同時沒有足夠的擴展能力。

銀行雖然有很高的可用性,但是它的高可用性是用很高的硬體成本換來的。

我們建議一定要淘汰這些高可靠的硬體,因為他們的成本實在太高了

。一旦真的使用了高性能,高性價比的 PC 伺服器,那麼你就不可能再花那麼多錢去買高端的硬體。

所以我當時心裡很明白,如果這件事情我們做不成,這個項目就只有死路一條

那麼,OceanBase 到底如何做到主備完全一致的呢?理論上我們也沒有辦法說完全做到主庫備庫的一致。我們用了另外一個辦法:

主庫還是主庫,還是需要它快速的做事務,但同時主庫還要把事務的日誌同步給至少兩個備庫

。兩個備庫中至少有一個收到了,那麼加上它自己就超過了半數,或者我們叫多數派。當多數的節點收到了這個事務,並且把它持久化到硬碟了,我們就認為這個事務是成功的。

所以這時候任何一台機器壞掉,每筆事務在剩下兩台機器裡面至少一台存在。所以說即使主庫突然壞掉,另外兩台機器經過握手,它們再選舉出一個新的主庫,那麼肯定可以繼續工作下去,同時可以保證數據是沒有損失的。

2014 年的時候,我們在會議室里討論

支付寶交易庫的上線

,當時吵得面紅耳赤,爭論了很久別人就是不願意上 OB。他們原來的交易、支付系統全都在 Oracle 上,當時的 Oracle 無論是在穩定性、可靠性還是性能方面,肯定比 OceanBase 要好得多。所以沒有人願意用。

最後,在

魯肅(螞蟻金服 CTO)

的力挺下決定切給 OceanBase 1% 的流量試試。因為那幾年業務發展的太快,當時 Oracle 的共享存儲已經扛不住這個流量,按照當時的業務流量去做壓測的時候,幾分鐘就要壞一塊盤。最後發現,把業務切掉 10%,才能勉強扛得住。

所以那一年的雙 11 就把 10% 的流量切到了 OceanBase。OceanBase 也成功扛過去了那一年的雙 11

OceanBase 1.0 版本:唯一支持分散式事務的商業資料庫

但是其實在 0.5 這個版本上線的時候,我們心裡非常清楚,這個版本是臨時的。我們當時選擇做多數派協議的時候,還是用了原來的想法,每個集群還是中間有一個中心節點。這個事情一定不會是長久持續下去的,我們知道這個一定會遇到問題。所以當時其實交易庫還沒有完全上線,我們就已經啟動了 1.0 版本的開發。

2014 年到 2016 年,整整兩年的時間,我們投入了 40 多個人,全部投在 OceanBase 1.0 版本的開發上。整整兩年,這 40 多個人沒幹任何別的事情。所有的線上問題,版本修改、升級都是我們調出來的五個同學全部扛下來的。

有人會問什麼樣的因素讓這麼多人做了兩年才能把這個版本做出來?這個版本裡面我們主要做的一件事就是分散式。

如果你問分散式事務有這麼難嗎?我可以自豪地回答你:

今天的商業資料庫里有且只有一個是能夠支持分散式事務的,它就是 OceanBase

OceanBase 通過分散式的一致性協議做到了系統的高可用性,就是說哪怕我們今天用的是比較廉價的,可靠性比較低的 PC 伺服器,但是我們的可用性其實會變得更高。因為單機的故障我們完全能夠自動的容忍掉,而且我們做到了現在的數據做不到的一件事情——

哪怕主庫出故障,我們能夠保證數據沒有任何損失

今天的銀行每年國家都要求他們至少做一次消防演習,銀行要到最前端的網關把交易紀錄撈出來核對,把這些賬對平了,備庫才能繼續服務。我們今天根本沒有這個問題,主庫出故障了,也就是幾十秒以後,新的主庫就會被選出來。因為只要剩下的機器超過半數,他們互相之間會通過握手把數據補齊,很快就能工作。其實這 30 秒大部分還是消耗在確定主庫是否真的有故障。

所以,我們用不可靠的硬體反而做到了更高的可用性,而且做到了數據真正的一致。

傳統的資料庫因為涉及到共享存儲,共享存儲是一個單一的設備,你只能放在一個機房。所以一旦那個機房出現了故障,你就只能靠備庫容災把系統恢復起來。

OceanBase 通過「三地五中心」部署實現城市級故障自動無損容災

。比方說相當於你一共寫了五份日誌,放在三個不同的城市裡。任何一個城市哪怕出故障,比方說杭州斷網了,那麼剩下的依然超過半數,這個系統還是可以恢復工作的。這也是原來的傳統資料庫,不管想什麼辦法,都做不到的事情。

9 月 20 日雲棲大會 ATEC 主論壇現場剪光纜實況

前段時間,大家可能也看到了雲棲大會的新聞。螞蟻金服副 CTO 胡喜在 ATEC 主論壇現場模擬挖斷支付寶近一半伺服器的光纜。

結果只過了 26 秒,模擬環境中的支付寶就完全恢復了正常

。而這場 26 秒自斷伺服器現場演示的技術核心其實正是基於 OceanBase 的三地五中心架構方案。

2017 年,天貓雙 11 中螞蟻金服的全部核心系統,包括很多業務系統都放在了 OceanBase 上。去年我們創造了

25.6 萬筆 / 秒

支付峰值的世界紀錄,這下面還有一個數據,就是說我們為了要執行這 25.6 萬筆的支付,執行了

4200 萬條 SQL

3

新的歷史機遇:走出去

所以從今天來看,OceanBase 在過去的歷史進程中面臨了一個個新的機遇,無論是處理器、操作系統還是資料庫,這些都是非常大的挑戰。

從 2016 年底,我們就開始做準備,OceanBase 一定要走出去。從我們成立的第一天起,團隊里的每個成員的目標都是一致的:

我們不是想做一個資料庫只是給自己用,我們要做一個資料庫真的去推動整個社會的進步,能夠讓整個社會的生產力發生變化

所以,2017 年我們正式開始服務於外部,最早的兩家客戶是

浙商銀行

南京銀行

,我們現在的客戶要多很多。從內部的應用到真正走出去服務於外部,真的是一個很大的挑戰,是一件很困難的事情。

回想這八年多來,OceanBase 走過的路:開始的頭兩三年,我們真的每天都在掙扎,每分每秒都在想著怎麼能讓自己活下來。到了 2013、2014 年,我們終於找到了一個真正的立足點,就是支付寶的交易庫。然後我們接著花了整整兩年的時間,真正在 OceanBase 1.0 版本把分散式做出來。在接下來的一到兩年時間裡,我們把支付寶的核心業務全部搬到 OceanBase 上。

關係資料庫確實是個門檻很高的東西,但是凡事有利有弊。門檻高意味著我們進來很難,別人進來一樣難。我們集中精力在做事務處理這一塊,它的門檻是很高,很不容易進去,但我們恰恰有這個機會能進去。我們費了很大的力氣跨進來了,別人可能費了全部力氣也進不來。

現在回想起來,能夠把最早的一些想法一些創新變成產品,真的是非常辛苦或者說非常痛苦的一條道路。但是我們做的所有事情其實還是從業務、從客戶中出發,只有技術真的能夠落到生產中去,落到用戶中去才是真正有價值的,否則你做得再好也是一個空中樓閣。

到了今天,當我們走出阿里巴巴,走出螞蟻金服再來看,發現

當你做的事情能夠提供十倍性價比的時候,其實真的有機會去顛覆一個產業,重新塑造一個行業

4

友情推薦

OceanBase 是由螞蟻金服、阿里巴巴完全自主研發的金融級分散式關係資料庫,始創於 2010 年。OceanBase 對傳統的關係資料庫進行了開創性的革新。在普通硬體上實現金融級高可用,在金融行業首創「三地五中心」城市級故障自動無損容災新標準,同時具備在線水平擴展能力。在 2017 年天貓雙 11 中創造了 4200 萬次 / 秒處理峰值的世界紀錄。在剛剛結束的 2018 年天貓雙 11 中,OceanBase 2.0 版本支撐了支付寶的核心鏈路,性能比去年提升了 50%,真正實現了「零成本」支撐大促。歡迎關注「OceanBase」公眾號,了解更多資料庫乾貨,破解今年天貓雙 11 突破 2135 億元成交額背後的技術密碼。

今日彩蛋

如果你想了解更多關於開源資料庫的知識:方案、設計思想及適用場景,可在 InfoQ 後台回復關鍵詞:

資料庫

,即可獲取相關乾貨文章。


註:請在公眾號對話框回復關鍵詞,留言區回復收不到鏈接哦~


今日薦文

點擊下方圖片即可閱讀


Kafka 的七年之癢








福利時刻

AI 在物流、金融、電商、教育、視頻等領域的最新落地應用有哪些?學習來自 Google、微軟、BAT、360、京東、美團等 40+AI 落地案例,涵蓋機器學習、知識圖譜、NLP、搜索推薦、語音識別等熱門技術,乾貨滿滿。

12 月 20-21,相約 AICon,與 40+ 國內外一線 AI 技術大咖面對面交流,不見不散。

AICon 北京 2018 日程已上線,

8 折報名倒計時 5 天

使用優惠碼「AICon」可享立減 920 元的特殊福利!名額有限,先到先得,詳情諮詢:18514549229(微信同號),點擊「

閱讀原文

」獲取完整日程。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 InfoQ 的精彩文章:

沒看過這條鄙視鏈,別輕易說你懂區塊鏈
27歲的Linux和49歲的Linus:PC操作系統太貴了,自己寫個吧

TAG:InfoQ |