OceanBase:螞蟻爬上舞臺

淺友們大家好~我是史中,我的日常生活是開撩五湖四海的科技大牛,我會嘗試各種姿勢,把他們的無邊腦洞和溫情故事講給你聽。如果你特別想聽到誰的故事,不妨加微信(微信號:shizhongmini)告訴我。

OceanBase:螞蟻爬上舞臺

文 | 史中

2010年過去了,我很懷念它。

這一年發生了很多場著名戰鬥:喬布斯一邊和病魔對抗一邊和谷歌纏鬥,並且抽空發佈了 iPhone4,用人生最後一段光陰拉開了移動網際網路的大幕;360和騰訊也打得不可開交,像甄嬛一樣爭奪桌面時代用戶們最後的寵幸;達摩面壁的天河一號超越「美洲豹」,第一次代表中國奪下世界上超算的寶座。

這一年還發生了一場「非著名」戰鬥:甲骨文 Oracle 在最權威的資料庫性能測試「TPC-C」中跑出史詩級高分30249688,一騎絕塵飆到了死對頭 IBM 的將近三倍,為數年的纏鬥畫上鋼鐵般的句號。

Oracle 提著帶血的刀站在鬥獸場中心,大喊:「還有誰????」虎嘯山林,萬馬齊喑。

此後各個國家的銀行轉賬、存款保險、航空客票、電子商務的每一筆交易,凡是涉及數字和錢的,都要存在 Oracle 的資料庫上才最放心。這個星球上幾十億人的衣食住行,生生把甲骨文創始人拉里·埃裡森推上了福布斯富豪榜第五位。

也正是在這一年,兩個人在陽振坤的腦海裡結結實實打了一架。末了,他還是背起包,溫文爾雅地遞交了辭呈,從百度大廈搬到了阿里大樓。

陽光刺眼,未來並不是清晰可辨。

(一)「賬本危機」

(一)「賬本危機」 

我們的故事不妨先從葫蘆娃說起。

打敗蛇精之後,爺爺把妖精的金銀財寶都抱回村子,帶著葫蘆娃在村口開了一個小銀行——「葫蘆娃農村合作信用社」。他們搞了一個小賬本,用來記錄每天鄉親們存了多少錢,取了多少錢,轉了多少錢。由大娃專門負責記賬。

爺爺經營有方,銀行越做越大,然而問題也隨之而來:

每天資金流水數以億計,需要一個超厚的賬本才能把賬記全。於是爺爺找到賣賬本的老闆:「我想定做一個超級厚的賬本。」沒想到賬本老闆一攤手:「對不起,工藝限制,我們做不出更厚的賬本了。。。」

眼看銀行還在不斷做大,腫麼辦?爺爺只好從老闆那買了好幾個獨立賬本,把鄉親們的戶頭分在不同的賬本上,讓每個葫蘆娃分別記賬。

這個辦法解決了記賬的燃眉之急,卻帶來了一個新問題——每天晚上銀行要盤點總賬,但由於賬本是分割的,沒辦法彙總。爺爺只好派七娃在每天打烊之後,專門把所有賬本的關鍵數據都抄在一起,做成一個「數據倉庫」,在倉庫裡做最終的彙總、報表。

然而「不解風情」的用戶還是繼續從四面八方湧來,銀行家爺爺為了服務好這些用戶,每天都讓七娃用各種姿勢算數據,七娃不堪重負,仰天長嘯:「本來以為蛇精就夠狠的,沒想到最狠的是爺爺。。。老子要辭職!!!」

這不是童話,是差一點就要發生的現實。故事裡的「銀行」就是支付寶,「賬本」就是資料庫,「賣賬本的老闆」就是資料庫公司甲骨文(Oracle),而「葫蘆娃」就是支付寶的伺服器。

那是2013年,支付寶實名用戶數超過3億,全年支付27.8億筆,穩坐中國網際網路支付平臺第一把交椅。舞臺上歌舞昇平,舞臺基座卻開始微微顫抖——用來存儲用戶數據的 Oracle 資料庫就像一個氣球,此時已經被撐到極限,誰都不知道「砰」的一聲何時來臨。

「賬本危機」像是露出海面的鯊魚鰭,雖然目前一切仍在掌握,但海面之下卻是血盆大口。留給中國隊的時間不多了。

2013年夏天,時任支付寶 CTO 魯肅召集各位技術大佬開會商量這個問題,所有人都表情凝重。說來說去,似乎也只剩一條路——像「爺爺」那樣先把資料庫拆成幾份,解了燃眉之急,後面的事再從長計議。

就在這時,一位老哥悠悠地說:如果各位信任我,用「分佈式資料庫」代替 Oracle,我向大家保證,我們能把資料庫做到無限大!

大家齊刷刷看向他,目光各異。

沒錯,這位老哥就是三年前加入阿里巴巴的陽振坤,他口中的「分佈式資料庫」,就是他帶著同學們從零開始研發,彼時剛滿三週歲的 OceanBase。

(二)「無限大」的夢想

(二)「無限大」的夢想 

首批長江學者,國家科技進步一等獎得主,王選院士的愛徒,激光照排技術的重要貢獻者,中國分佈式計算的推動者,分佈式金融級資料庫 OceanBase 的創始人,要是陽振坤把這些頭銜都做成勳章,可以像蘇聯元帥一樣把胸前掛滿。

但是勳章冰冷,稜角難近。

所以,在我的故事裡,陽振坤沒有那些頭銜,也不是比我父親小三歲的大叔,他一直是那個1984年考上北大數學系的19歲少年。

陽振坤

陽振坤

陽振坤第一次接觸分佈式系統,還是在2006年,那一年他加入微軟亞洲研究院。

微軟亞洲研究院,是中國計算機科學的黃埔軍校。李開復、張宏江、沈向陽、湯曉鷗、王曉峰、餘凱這些燦若星辰的大牛,幾隻手都數不過來。而當時陽振坤彙報的對象,是個比他大三歲,但和他一樣倔的老哥,此人名叫王堅。

技術人都有股清高,雖然那一年陽振坤幾乎天天和王堅「吵架」,但是他倆在內心裡卻有了一個大共識——分佈式系統才是這個世界的終極未來。

中哥賣了半天關子,到底什麼是「分佈式系統」?下面就緊急插播一段科普。

分佈式系統的原理很簡單:把一個大機器乾的活分給無數個小機器一起幹,從而大大提高系統的整體性能。(這個設想最初是由谷歌在2006年提出來的。)

舉個栗子:

1、關二爺斬顏良誅文丑過五關斬六將,但他就是再厲害,世界上也只有一個關二爺。一人獨自面對百萬大軍腿也軟。關二爺就叫「單機」。

2、關二爺一個人不行,把劉備關羽張飛捆在一起呢?雖然是兄弟三人並肩作戰,但他們三個還是獨特的,不能無限複製。劉關張就叫「集群」。

3、諸葛亮運籌帷幄,指揮蜀軍帳下千軍萬馬,東擋西殺,部分將士有死有傷,也並不影響整個軍隊完成戰爭使命。一場戰役下來還可以繼續招兵買馬,擴充實力。蜀軍就叫「分佈式系統」。

你可能會說,中哥怎麼還整出來《三國》了,分佈式系統聽上去跟我沒啥關係啊。。。

你錯了,摸摸口袋,只要裡面裝著智能手機,這事兒就鐵定和你有關——你去餓了麼點外賣,去淘寶剁手,在微信聊天,十幾億人每天無數次次數據交互、調度、運算都是由「雲計算」完成的。而「雲計算」其實是個小名,它的大名恰恰就叫「分佈式計算系統」。

一句話:沒有分佈式系統,就沒有我們今天的世界。

相比「單機系統」和「集群」,「分佈式系統」有兩個明顯的好處:

1、扛造。

打個比方:螞蟻社會就是個分佈式系統——這個家族的生存任務被分攤在每一個螞蟻頭上;出門執行任務的個體螞蟻難免遭遇鞋底、車輪等等不測,但這並不會影響整個蟻穴的運轉;而且就算蟻后被捉走,螞蟻們也能臨危不亂迅速選出新蟻后,繼續產卵生子母儀天下。

2、無限大。

道理是很簡單的數學:1+1=2,1+1+1+1+1……無數個1加起來就是無限大。只要在技術上實現對每一臺機器的「自動調度」,分佈式系統就是沒有上限的。

別忘了,命運贈送的禮包越大,暗中標定的價格就越貴。老司機攻克「分佈式系統」的技術,難度不亞於奪下惡龍守護的珍寶。

江山多嬌,無數英雄競折腰。

說回我們的故事。陽振坤和王堅都有濟世情懷,不願意「躲在小樓成一統」,而是夢想著讓自己手中的技術能給世界帶來肉眼可見的改變。

於是,2007年陽振坤去了百度,2008年王堅去了阿里巴巴。他倆做了同一件事兒——雲計算。

歷史的裂痕就此綿延。當時的「網際網路一哥」李彥宏羽扇綸巾,全情投入夢想中的人工智慧,卻把雲計算稱為「新瓶裝舊酒」;而千里之外的杭州,不懂技術的馬雲卻被王堅「忽悠」,拿出了十個億支持他做「阿里雲」。

王堅

時間終於走到了2010年,文章開頭的那一幕出現——陽振坤「未敢翻身已碰頭」,在阿里巴巴合夥人劉振飛的邀請下,終於下定決心出走百度,轉投阿里巴巴。

來到阿里巴巴,繼續做熟悉的雲計算應該是順理成章的事兒。不料,陽振坤的老司機本色開始顯露。。。

離開前一家,之前的項目我就不會再做,因為之前的技術、關係網很多,容易引起糾紛,讓別人說閒話。我離開方正後,就不做激光照排,離開百度後,就不做雲計算。

陽振坤解釋。

這種「避長揚短」的孤傲著實令很多人費解,但他就是這樣做的。

那麼問題來了, 除了雲計算,哪個技術最有前途嘞?挑來挑去,他選中了「分佈式資料庫」。

為啥是資料庫?

這和王堅當時在阿里巴巴力主推行的「去 IOE 行動」有關。

2009,是「雙11」元年,阿里巴巴如火山待燃。為了給剁手黨們提供頂級的服務,無論是淘寶還是支付寶,都大批購買昂貴的 Oracle 資料庫,把用戶的核心數據跑在上面。

但是,盛世和危機只有一線之隔。

你還記得第一章我們講的支付寶「賬本危機」嗎?淘寶同樣遇到這個問題,而且要比支付寶更早:

2010年時,一個 Oracle 資料庫已經沒辦法支撐淘寶巨大的交易數據,危機迫近,淘寶只好像「爺爺」一樣,把資料庫拆成相互獨立的子資料庫,然後用「數據倉庫」的方式每日彙總。

然而問題來了,假如把1個大資料庫拆成100個子資料庫,100個子資料庫就要買100個 Oracle 軟體授權,為了運行這些資料庫還同時要配備100臺(或更多)IBM 小型機,還有相應的 EMC 高端存儲(這三個並稱IOE)。

這可不是開玩笑的,把阿里巴巴所有的利潤拿來買這些「奢侈品」都不夠。。。

王堅手捧預算,鐵血站在此地,從此時此刻起不準購買一套新的 Oracle,退半步者,斬立決。

於是,當時淘寶把資料庫拆分後,很多子資料庫都換成了開源的 MySQL 資料庫,只有少部分最核心的數據仍然跑在既有的 Oracle 上。(你可以簡單把 Oracle 理解為 iOS,把 MySQL 理解為安卓。MySQL 開源免費,比 Oracle 實惠得多,但二者都是同一代技術——集中式資料庫。)

然而從陽振坤這個「技術完美主義者」的角度來看,用 MySQL 代替 Oracle 並不解決根本問題,因為這種「拆賬本」的方式本身就是下策。他甚至想:如果自己能早點來,早幾年開發「分佈式資料庫」,直接用分佈式資料庫代替 Oracle,不僅能去IOE,還能避免「拆賬本」的情況發生,一舉兩得。

但歷史沒有假設,種一棵樹最好的時機是十年前,第二好的時機就是現在。

陽振坤這位老司機,就這樣分秒必爭地開車衝上「分佈式資料庫」這條賽道。

只是彼時的他,尚未預料到資料庫這條路比秋名山還凶險。。。

分佈式資料庫技術具體有多難呢?

分佈式資料庫技術具體有多難呢?

簡單說,要想賬頭一分錢都不錯,資料庫要符合一個叫做「ACID」的原則,這四個字母分別代表:A原子性,C一致性,I隔離性,D持久性。

原子性:A轉給B100塊錢,A賬戶扣除100塊的同時,B賬戶必須增加100塊錢。這兩件事必須像一個原子一樣緊緊抱在一起,決不允許「A已經扣錢,B還沒加錢」的事情發生。

一致性:A轉給B100塊錢,轉賬完成的一瞬間,A瞬間再查詢自己的最新餘額,必須顯示已經扣除100之後的金額,B必須瞬間查到已經加上100塊之後的餘額。所有的賬目在任何一個時間切面必須完完全全對得上。

隔離性:A轉給B100塊錢,不能對C有任何影響。

持久性:A轉給B100塊錢,這筆轉賬一旦完成,就永遠生效。

問題來了:

如果是集中式賬本,只有一個葫蘆娃負責寫入,保證 ACID 就容易得多;

但是分佈式資料庫是讓無數個葫蘆娃千手萬腳地在一個超大型賬本上記賬,相當於指揮整個幼兒園的熊孩子整齊劃一地左手畫龍右手彩虹胸口比劃郭富城,此時要保證 ACID,就比登天還難。

一句話:2010年的世界上,能保證 ACID 的「分佈式資料庫」根本就不存在。

當時淘寶的核心技術由吳泳銘負責,他是阿里巴巴第一位程式設計師,早在阿里建立之前就跟隨馬雲東擋西殺,人稱「吳媽」。(其實是男的。。。)

吳媽伸出兩個指頭:「陽老師,我可以給你兩年的時間來證明「分佈式資料庫」是可行的。」

陽振坤呵呵一笑:「用不了。」

「後來的事實教育了我,分佈式資料庫是所有分佈式系統裡最難的那個。。。」

坐在我對面的陽振坤苦笑。

陽振坤,拍攝於2010年

陽振坤,拍攝於2010年。

(三)「收藏夾」第一戰 

2010年6月,光桿司令陽振坤出街。

他眼前要處理的問題有千千萬,但最主要的就一個:沒人想用,也沒人敢用他的「分佈式資料庫」。

由於當時淘寶的資料庫已經拆分。拆都拆了,換上的 MySQL 又基本運行平穩,腦子正常的人誰也不會再折騰這件事兒了。

於是45歲的陽振坤拿著自己的 PPT 在淘寶各個業務線奔走宣傳,像極了一個亟需養家餬口的「大齡推銷員」。要是那時候有微信,他肯定每天兩萬步。

功夫不負苦心人,總算有一個團隊願意吃螃蟹,那就是淘寶裡的一個小版塊——收藏夾。

收藏夾團隊之所以要吃螃蟹,也不是因為他們看好分佈式資料庫,而是有一個實實在在的「難言之隱」。

什麼難言之隱呢?

來,回憶一下你使用收藏夾的過程。

假如你收藏了100件商品。點開收藏夾,100件商品就會瞬間跳到你的眼前,每一個商品都顯示它的實時狀態——比如最新價格是多少,是否下架,等等。

你可能想不到,就是這麼輕輕一點,卻苦了收藏夾背後的資料庫,那一刻它要去淘寶商品庫裡挨個調取每一件商品的實時詳情,相當於一瞬間把100件商品訪問了一個遍,再把所有需要更新的價格、狀態一一寫進自己的資料庫,最後呈現給你。(這一切都在零點幾秒內發生)

這裡要科普一個小知識:商品的價格信息往往就是一兩位數,換成計算機術語就是1-2個Byte,但由於技術限制,計算機對硬盤操作最小的單位是4KB,4KB=4096Byte。也就是說,如果資料庫只想改一個價格信息,它也必須讀出來一整塊4KB的數據,然後只修改其中幾個數字,再把4KB數據整體寫回資料庫。

藍色是讀出的整數據塊,紅色為其中修改的部分。注:由於數據讀出來之後,原存儲位置被釋放,所以一般會寫回到另一個地方。

所以,如果一次性讀取100個商品,雖然只有其中一小部分商品的參數發生變化,卻會對資料庫額外進行幾千倍的寫入,讓資料庫伺服器忙得不可開交——這就叫做「寫入放大」。

當時收藏夾的伺服器只有100臺,眼看人們在收藏夾裡堆的商品越來越多,團隊壯著膽子為明年申報了400臺機器的預算,就這樣還不一定夠。。。

陽振坤聽完了收藏夾團隊的難言之隱,眉頭一皺,計上心來。他的辦法如下:

「內存」這種東東沒有4KB的調取下限,而且讀取速度是硬盤的100倍左右,所以只要新設計一個資料庫,把商品的最新信息放在內存裡。用戶訪問收藏夾的時候,資料庫先去硬盤上把基礎的數據找來,再去內存裡讀取最新改動的部分,疊加之後呈現給用戶,問題就解決啦。

每過24小時,通常在後半夜比較閒的時候,資料庫會統一把前一天內存裡的「增量數據」寫入硬盤,清空內存,來日再戰。(這種閒時集中寫入還有個好處:可以把數據壓縮比做到極致,節省60%左右的存儲空間。)

你可能會問,這樣的話還要在內存裡標註每段數據對應著資料庫上的哪個位置,這不也是額外信息嗎?你說得沒錯,在每個數據旁邊,都要加一個指針,標明它是用於更新資料庫裡哪個參數的。但是即便加上這些信息,寫入放大也只有大概幾十倍,比硬盤的寫入放大低兩個數量級。(以當時收藏夾的狀況,10G內存就夠了。)

這樣算下來,收藏夾團隊用現有的機器就能輕鬆應對再多100倍的數據量。

聽上去很不錯吧。收藏夾的同學也覺得不錯,給了陽振坤老溼一個月的時間把吹出去的牛逼實現,結果陽振坤弄了八個月才交貨。。。。

為啥這麼久?

各位別忘了,解決「寫入放大」只是陽振坤的支線任務。他的主線任務是把這個資料庫做成「分佈式資料庫」。

當時陽振坤剛剛招了幾個應屆生同學——解決寫入放大,一個月真差不多;把分佈式資料庫的底座寫出來,一年算是快的。

雖然時間緊急,團隊還是決定給這個「分佈式資料庫」起個名字先。一位同學提議,既然我們的目標是星辰大海,要讓無遠弗屆的巨大資料庫降生在這個世界上,不如就叫「海洋」,翻譯成英語很好聽,叫 OceanBase。

矮油不錯哦,大家把這個主意告訴陽振坤,求誇獎。

陽振坤當時正急得焦頭爛額,說:「叫啥都行,咱們趕緊研究技術吧!」

OceanBase 的名字就這麼稀裡糊塗地定了。。。

具體來說,OceanBase 想要做成「分佈式」,得解決兩個難題:「分佈式讀」和「分佈式寫」。

先說簡單一點的「分佈式讀」。

收藏夾資料庫連著50臺終端機,終端機的角色就像銀行櫃員一樣,在普通用戶點開收藏夾的時候,它們負責對100臺伺服器組成的分佈式資料庫進行讀操作,然後把數據返回給用戶。

由於數據散落在100臺伺服器上,所以50臺終端機中的任何一臺都有可能連接100臺伺服器中的任何一臺,也就是50*100=5000條可能連接。但這個數目太大了,無法穩定維持,所以需要定期斷掉其中不常用的九成,同一時刻只留500條左右的連接。

如此,問題基本解決。

再說難一點的「分佈式寫」

再說難一點的「分佈式寫」。

對於這個問題,陽振坤的解決方案是——暫時不解決。

是的,你沒看錯。當時時間已經過去半年多了,而試驗了幾個技術方案,都沒有很好地解決「分佈式寫」的問題,OceanBase 拖著交不了貨,收藏夾團隊氣得要死。講真,收藏夾團隊關心的「寫入放大」問題已經解決了,「分佈式的寫」能不能搞定,那是你陽振坤自己的追求。

眼看2011年的「雙11」就要來了,一大波剁手黨即將抵達戰場。目測如果 OceanBase 再不交貨,收藏夾鐵定要跪,他們已經開始磨刀準備來砍人了。。。

沒辦法,OceanBase 只好暫時放棄技術攻關,把寫入增量數據的內存都集中在其中一臺機器上(集中式寫入),就這樣交付了。

有意思的是,OceanBase 團隊保持著一貫「不輸嘴」的高傲,把這個版本命名為 OceanBase 0.1 版,意思就是:這個東西在我心裡只完成了一點點,哼!

0.1 就 0.1 吧,對於收藏夾團隊來說足夠解決燃眉之急。雖然還有不少小 Bug,但幸好都在「雙11」之前排查清楚,收藏夾擦著冷汗,安全衝過那年「雙11」。

OceanBase 首戰告捷。

嗯。。。基本告捷吧。

(四)「兩年倒計時」和出走支付寶 

陽振坤站在廣場上吆喝:「收藏夾第一個吃了螃蟹,誰願意做第二個?」

大家都往後退了一步。。。

2012一整年,陽振坤瘋了一樣把團隊十幾個同學都派出去,逮住人就問:你要不要用 OceanBase?

然而,只有零星幾個小業務「禮貌性」地用了 OceanBase,不值一提。大家暗地裡口耳相傳:聽說了麼,OceanBase 能把一個月的活兒幹成八個月,雙11前還在修 Bug,差點把收藏夾給坑了。。。

不過陽振坤卻不完全認同:

資料庫就和年輕人一樣,是磨練出來的,越用才能越發現問題所在。你看 Oracle,那是磨練了四十年的結果,如果一個大學生剛剛參加工作,老闆總不給他機會,那他怎麼成長呢?

道理大家都懂,可是真求到哪個業務,業務同事們又都咂咂嘴,語重心長:陽老師我不是不幫你,我這不太合適啊。。。

就這樣,時間推進到了2012年秋天,吳媽的「兩年之約」眼看就到了。結論很明顯,「分佈式資料庫」沒能證明自己,陽振坤站在信任的荒原上,心急如焚。

10月底,陽振坤再也忍不住了,一拍桌子,從北京飛到杭州,坐在了阿里巴巴 CTO 兼老同事王堅的辦公室裡。

王堅能幫他麼?不好說。

說實話,那段時間王堅自己的日子也並不好過。他力主創造的阿里雲,同樣是從零開始研發,彼時正經歷大家最激烈的的嘲諷和白眼。大批優秀的程式設計師實在看不到光明,在這年秋天深鞠一躬,就此別過。阿里雲搖搖欲墜。(

《阿里雲的這群瘋子》

兩人相對無語。做成一件事有多難,彼此心裡誰不清楚呢?末了,王堅對陽振坤說:「你放心,先回去吧。我心裡有數了。」

兩週之後,一紙調令在集團公佈:

2012年11月15日,OceanBase 所有人員從淘寶調入支付寶。

把 OceanBase 團隊調入支付寶,王堅是有戰略考慮的。

1、淘寶已經把「賬本」拆分,而且用了開源的 MySQL 代替了 Oracle,不適合冒險使用理念這麼超前的資料庫。

2、支付寶尚未把「賬本」拆分。究其原因恰恰是它直接和錢打交道,對於數據的安全要求極高,如果用 MySQL 代替 Oracle,以當時的技術發展水平有一定的風險,不敢輕舉妄動。

3、如果在支付寶,OceanBase 有能力獲得信任,有朝一日直接替代 Oracle,支付寶的資料庫技術就不僅去了 IOE,還不用拆賬本,還實現了技術躍遷,一箭三雕。

當然這一切只是王堅的設想,他也只能幫到這了。餘下的,就看老夥計陽振坤有多少真本事了。

果然,加入支付寶幾個月後,第一章提到的「賬本危機」就不得不提上日程了。

「如果各位信任我,用「分佈式資料庫」代替 Oracle,我向大家保證,將來我們能把資料庫做到無限大!」

此刻你再體會陽振坤在會上說的這句話,就已經不是一個技術大佬的低調炫耀,反而頗有背水一戰的味道了。

聽完陽振坤的毛遂自薦,魯肅沉默很久,提出一個直擊靈魂的問題:

你 OceanBase 用什麼技術來保障賬戶不丟一分錢?

陽振坤敢攬瓷器活,一定是懷裡有金剛鑽。過去一年,雖然沒有大的業務「臨幸」,但是 OceanBase 的技術一直在同事們的努力下穩步迭代。

OceanBase 解決這個問題的方法就是「三副本」。

「三副本」是個啥?

1、三套 OceanBase 資料庫綁在一起工作,一個做「主咖」,兩個做「備胎」。假如你在支付寶上發起一筆轉賬,這個信息會同時發給三個庫。

2、主咖接到轉賬申請後,先不著急記錄在案,而是詢問兩個「備胎」,你們是不是也收到了這筆申請。

3、至少一個備胎回覆「收到」以後,主咖才會把這筆交易記錄在案。於是,每一筆交易都會保證至少由兩個資料庫記下來,所以任何一筆交易都不會丟失。

這種操作不是陽振坤的原創,而是源自1989年的一篇論文,最早的實際應用大概是在2000年左右的谷歌內部。只是在2013年的中國,還沒有人這樣擺弄資料庫。

平心而論,魯肅是不世出的技術天才,一個技術能不能管用,有沒有漏洞瑕疵,他用鼻子都能聞個八九不離十。聽完這個技術構想,他說:「陽老師,我支持你去試試。」

魯肅的話說得很謹慎,這也是不得已。

如果 OceanBase 的步子邁得太慢,那麼支付寶面對迫近的「賬本危機」就可能少一樣重武器,吉凶未卜;如果 OceanBase 的步子邁得太快,萬一技術真有缺陷,但凡丟了用戶一分錢,對支付寶的聲譽都是毀滅性的打擊。別說魯肅,誰都負不起這個責任。

不過,至少得到了口頭支持,陽振坤開心地回到團隊,帶領大家開始了 OceanBase 的「三副本」升級。

又是一年寒暑。

(五)從1%到10%,從0.1到1

到了2014年5月,OceanBase 三副本終於就緒,版本號升級為 0.5。

可是那個夢魘一樣的老問題又出現了——沒有業務團隊敢吃螃蟹。。。至於為什麼不敢用 OceanBase,又都說不上來。他們只是支支吾吾:感覺不穩定,害怕性能差,擔心出問題。

就這麼幹挺了兩個月,每一天對於陽振坤來說都是漫長的煎熬。他終於忍不住了,給魯肅、井賢棟和螞蟻金服 CEO 彭蕾發了一封郵件。

團隊的同學們看我的眼神,每天都從希望到失望,我是真的不知道怎麼給他們交代。情急之下,才冒昧寫了這封信。

陽振坤回憶。

那封信發出一星期後,魯肅找到陽振坤:「在接下來的雙11,OceanBase 會承擔支付寶交易流水庫 1% 的流量,我叫了交易流水團隊的同學,咱們一起對接!」

魯肅親自坐在督戰室,對業務團隊的同學說:你說說看,OceanBase 到底有什麼問題,要說具體的,不能說「感覺不穩定,害怕出問題」這些虛的。

我特別感謝魯肅,雖然只是給了流水庫的1%,但是他當時肯定承受了巨大的風險和壓力,這是對我莫大的信任。

陽振坤對我說。

流水庫的 1% 由 OceanBase 承擔,那剩下的 99% 呢?當然是老牌選手 Oracle。

然而戲劇性的一幕出現了。

就在雙11來臨之前,阿里巴巴會進行「全鏈路壓力測試」——模擬雙11當天的流量洪峰,檢查技術上有沒有疏漏。

結果,承擔99%流量的 Oracle 屢次崩潰,無論如何通不過測試,而一旦把它承擔的流量降為90%,就恢復正常。。。事實已經很明顯:Oracle 的實際性能極限已經被觸碰到了。

於是就在雙11來臨前兩週,魯肅臨時修改計劃,讓 OceanBase 承擔10%的流量,陽振坤團隊臨危受命。

11月10日晚,螞蟻金服 CEO 彭蕾專門來到 OceanBase 的作戰室,問陽振坤:「陽老師有信心嗎?」

陽振坤指指窗戶,窗外深秋的樹葉正在風中婆娑。「不成功我們就跳下去。」他平靜地說。

「當時你們在幾樓?」我問。

「7樓。」他說。

「如果沒成功,你真的會跳嗎?」我問。

「我們的 OceanBase 實際上部署了承擔100%交易資料庫的能力,也就是說如果 Oracle 完全不起作用,我們也能扛起來,這個技術自信我是有的。」陽振坤笑。

現在陽振坤活生生地坐在我面前,你應該能猜到,那次「雙11」的結果可以用完美來形容。

OceanBase 一戰成名。

2014年底,阿里巴巴集團召開了「雙11」覆盤會。陽振坤作為演講者,從頭到尾分享了 OceanBase 的技術構想和艱辛歷程。

這一場分享,深深烙在陽振坤的記憶裡,揮散不去。

正是從那時起,OceanBase 這個曾經被「嫌棄「的少年,一點一點努力奔跑,擺脫了死神的追擊,被越來越多同事和技術人發自內心地接受和尊敬。

OceanBase 後來獲得了2015年螞蟻金服最重磅的獎項——SUPER MA。這是時任螞蟻金服 CEO 彭蕾在給 OceanBase 團隊頒獎。

OceanBase 果然人如其名,真的和海洋一樣,差點把創始人都」淹死「。。。陽振坤在水面之下潛行五年,此刻也終於可以浮出海面,舒爽地換一口氣。

不過也僅僅是換一口氣——此時擺在他面前的,還有那個早就應該解決的大難題。

你還記得嗎,OceanBase 還是個半成品,它只解決了「分佈式讀」的問題,沒能解決「分佈式寫」的問題。

其實,經歷了兩年多時間,這個問題的解決方案在陽振坤的腦海裡已經成熟,只是團隊生死未卜,一直沒能騰出手來做升級。

接下來中哥就給你科普一下「分佈式寫」是怎麼解決的。

分佈式寫最大的難度其實就在於保證 ACID 中的那個 A——原子性。

還是舉那個例子。

假設 A 給 B 轉100塊錢,由於是「分佈式資料庫」,A用戶的賬戶存在A機器上,B用戶的賬戶存在B機器上。

如果交易發生時,負責給A賬戶扣100塊錢的A機器死機,沒有扣成功,而負責給賬戶B加100塊錢的B機器工作正常,加上了100——這就會造成支付寶損失100塊。

反之,如果負責給A賬戶扣100塊錢的A機器正常,已經扣掉100,而負責給賬戶B加100塊錢的B機器死機,100塊沒加上,那麼用戶就會損失100——最後支付寶還要賠償用戶100塊。

為了保證以上這兩種尷尬的局面不發生,OceanBase 1.0 採用了整整一組技術,但最主要的是兩個,我給你講講。

1、投票機制。

剛才說過,資料庫是「三副本」,也就是任何一個賬戶,都有一個主咖兩個備胎共三份相同的數據。

舉例來說:賬戶A的數據一定同時存在三臺機器上。轉賬時,至少兩臺機器執行完畢才算轉賬完成,

這意味著,三臺機器裡有一臺壞掉,並不影響轉賬的執行。

同時,三臺機器之間相互實時發送「心跳信號」,如果有一臺機器掛了,其他兩臺馬上就能感覺到,處理完手頭這個交易後,馬上向系統發送警報,系統自動為他倆匹配一個新搭檔,三臺機器繼續工作。

而換下來那個壞機器,交給技術人員維修,修好後重新上架成為備用機器,等待進入戰鬥序列。

也就是說,除非兩臺機器在同年同月同日同分同秒同毫秒壞掉,否則資料庫的工作不受影響。

即使是這還不夠,在關鍵的節點,OceanBase 會採用五個節點投票。也就是除非三臺機器在同年同月同日同分同秒同毫秒壞掉,否則資料庫的工作不受影響。這個概率已經低到塵土裡了。

2、監督機制

2、監督機制。

仔細想想,除了機器壞掉,還有一些情況會破壞交易的原子性。

例如:A賬戶要扣掉100塊,但是它的餘額只有90塊,或者已經達到了今天的轉賬限額,這種情況下,如果貿然給B賬戶加了100塊,A賬戶卻不夠扣,就會陷入麻煩了。。。

反之如果B賬戶狀態有異常,不能加100塊,同樣會有麻煩。

解決這個問題的方法,就是引入一位「裁判員」。

裁判員站在A賬戶和B賬戶旁邊,它的工作流程是醬的:

1)裁判員問A賬戶:你的三臺機器都沒問題吧?A賬戶說:沒問題。

2)裁判員問A賬戶:你的賬戶允許扣100嗎?A賬戶說:允許。

3)裁判員問B賬戶:你的三臺機器都沒問題吧?B賬戶說:沒問題。

4)裁判員問B賬戶:你的賬戶狀態能接受加100嗎?B說:允許。

5)這時,裁判員吹哨,A、B賬戶同時凍結。

6)A扣100,B加100,雙方向裁判彙報「成功」。

7)裁判員再吹哨,A、B賬戶同時解凍。

以上7步,都是按時間順序完成的,卡在任何一步,賬目都不會亂,一分錢都不會丟。完全符合「原子化」的要求。

監督機制示意圖,當然裁判員也由三臺機器組成。

直到解決了「分佈式寫」,分佈式資料庫的所有技術障礙才被打通,用於存儲新寫入內容的內存可以分佈在每一臺伺服器中,就像下面圖示:

就這樣,2016年,一個真正的分佈式資料庫 OceanBase 1.0 橫空出世。陽振坤跑了六年的夢想馬拉松,終於看到了第一個里程碑。

而自天空俯瞰,一場「角馬大遷徙」正在發生。

自從2014年支付寶交易流水庫採用了 OceanBase,螞蟻金服的其他業務開始一個個告別 Oracle,越過湍急的河水,衝向了分佈式資料庫 OceanBase 的彼岸。

這場遷徙越來越壯闊,在賽博空間裡揚起塵土,在技術人心中暴裂無聲。

到2017年底,螞蟻金服核心系統中的最後一個 Oracle 資料庫被 OceanBase 替代。從此,Oracle 只出現在螞蟻金服的歷史博物館中。

正如陽振坤所預料的那樣,幾億用戶對於 OceanBase 的淘洗磨練,不僅沒有擊垮 OceanBase,反而讓它的表現越來越穩定。OceanBase 處理的所有賬目,一分錢都不會錯。

不過,在陽振坤眼裡,Oracle 絕不是被他們秒掉的渣渣,恰恰相反,Oracle 一直是他們心中的榜樣——OceanBase 七年征程,只是接近了老大哥的背影而已,並無值得驕傲之處。

況且在2017年,OceanBase 和 Oracle 比較,還有一個硬傷。

是什麼硬傷呢?

你還記得「葫蘆娃農村信用社」的故事裡,爺爺為了服務好鄉親們,需要每天晚上讓資料庫用各種姿勢分析報表麼?

2017年的 OceanBase 分析報表的能力其實是很弱的。

究其原因,還是「分佈式」造成的——在「分佈式資料庫」的技術體系裡,A給B轉賬,C給D轉賬,這兩筆轉賬互不干擾,如果你非要問它倆哪個在前哪個在後,OceanBase 就無法精確統計了。用專業術語講就是:做不到事務的「串行化」。不知道先後,很多分析就做不了。

而老大哥 Oracle 由於是集中式資料庫,相當於所有交易都是一個葫蘆娃完成的,那顯然每一筆交易的先後順序都能排得清清楚楚,什麼姿勢的報表都能出,槓槓的。

為了解決「串行化」問題,他們必須馬不停蹄繼續奔向 OceanBase 2.0。

終於,在2018年,OceanBase 團隊搞定了串行化的技術,他們解決的方式是醬的:

在資料庫身旁,專門設立一個節點,這個節點什麼都不幹,只負責一件事——發號

你去飯店吃飯的時候,如果人太多,服務員會給你一個號對吧。這也是類似的原理:

1)資料庫裡的裁判甲要進行操作時,要先跟「發號員」申請一個號段,例如10000-20000號。

2)裁判甲把自己要做的操作在自己內部排好順序,例如10001、10002、10003。。。。。

3)這樣在整體資料庫裡,每一個操作就有了自己獨特的編號,且不會重複。例如「A轉100給B」這個操作是10005號,「C轉100給D」這個操作是20456號。那麼,「C轉100給D」就一定發生在「A轉100給B」之後。

搞定串行化之後,OceanBase 已經在功能上追到了 Oracle 的 40%左右。沒錯,用了八年只追上了 Oracle 的 40%,這就是中國公司和美國公司的真實差距。

但我們也不用妄自菲薄,由於採用了下一代的分佈式架構,OceanBase 實現了「無限大」的擴展性,在性能方面比 Oracle 高到不知道哪裡去了。

雖然「士兵甲」「士兵乙」單打獨鬥打不過關二爺,但是千軍萬馬生擒關二爺卻是情理之中的。這像極了《三體》中所描述的「降維打擊」——高維空間的螞蟻,可以穿透低維空間的大象。

OceanBase 2.0 全局示意圖

OceanBase 2.0 全局示意圖

(六)登頂「珠峰」 

雖然在螞蟻金服內部,OceanBase 已經接過 Oracle 的接力棒,但放眼望去,中國的無數銀行、金融機構卻沒有如此強的研發力量——他們仍然被困在低維空間,使用 Oracle 或類似的國外資料庫。

窮則獨善其身,達則兼濟天下。陽振坤決定兼濟天下。

2015年,阿里巴巴主導的銀行網商銀行使用了 OceanBase 資料庫。2017年,南京銀行的網際網路銀行業務使用了 OceanBase 資料庫。人保健康險、西安銀行、廣東農信等陸續有幾十家金融機構成為了 OceanBase 的用戶。

但是講真,這個數量比陽振坤預想中要更少。

因為他仍然面臨那個古老的命題:

想當年,可是魯肅、彭蕾、劉振飛、王堅、馬雲一眾大佬的信任,才讓 OceanBase 一步一個坎兒在螞蟻金服生根發芽,如今,各大銀行跟你螞蟻金服又不太熟,憑什麼放心地把最核心的業務跑在你開發的資料庫上?

陽振坤專門跑去問過很多銀行的技術領導:「你們不放心國產的 OceanBase,又為什麼放心美國的 Oracle 呢?」

銀行的同事說:「你去查查跑分啊,Oracle 是第一名,你 OceanBase 第幾名啊?都沒有在榜單上。。。」

銀行說的「跑分」,正是 TPC-C

故事講到這,TPC-C 終於又出現了。到底啥是 TPC-C 呢?

要明白 TPC-C,得先明白 TPC。

1967年,英國印刷公司職員約翰·巴倫突發奇想,發明了一種隨時隨地都能取到錢的自助提款機,也就是ATM機,80年代,ATM機開始風靡,由於無人值守,它的賬目就得通過自動化的資料庫來管理,於是各大軟體公司紛紛開始研發商業資料庫系統,準備趁著風口賺一票。

這時一個問題出現了, 王婆賣瓜自賣自誇。大家都說自己的資料庫好,究竟怎麼才是好呢?

於是工程師歐姆裡·塞林(Omri Serlin)說服了八家資料庫廠商,大家統一商量一個標準,就按照這個標準,用跑分的方式測試資料庫的能力,誰的分高誰就厲害,童叟無欺。

Omri Serlin

於是,一個專門負責幫大家跑分的組織就成立了,這就是 國際事務處理性能委員會 TPC(Transaction Processing Performance Council)。

TPC 會對資料庫很多方面的性能進行測試,而 TPC-C 是其中最主要的——針對在線交易資料庫的性能測試。

TPC-C 會模擬一系列的交易動作,例如下單、支付、訂單查詢、庫存查詢。誰能處理得最多,最穩定,誰的分就高。

另外,TPC-C 很自由,不限制你的資料庫跑在什麼伺服器上,只要你用的硬體是市面上公開銷售的就可以。所以,各家資料庫為了爭奪,八仙過海各顯神通,經常搞出奇葩的硬體組合。其中恩怨,一本金庸小說都寫不下。

總之,TPC-C 成為了資料庫界的「華山論劍」,誰跑分最高,誰就是武林盟主,不服不行。

不服也行,不服你就跑個更高的分看看。

陽振坤不服,OceanBase 要跑分。

你可能還記得,在我們故事的最開頭中哥講過:想當年,Oracle 在 TPC-C的測試中可是用跑分三倍於老對手 IBM 的華麗姿勢奪得的盟主。

如今 OceanBase 能不能同樣跑出 Oracle 的三倍呢?

陽振坤的結論是:不能三倍,可以十倍。

分佈式資料庫一定可以超越集中式資料庫十倍,甚至百倍,這是數學原理決定的。這也是我做 OceanBase 第一天就抱定的信念,不能超十倍百倍,我們為什麼要做?

陽振坤看著我。

就在這一瞬間,我面前彷彿坐著那個剛剛考上北大數學系,意氣風發的少年。也許有無數凶猛的敵人等在前路,也許越過山丘終究是一片荒涼。但此時此刻,他就是那樣無所畏懼,相信一切。

他把做 TPC-C 測試的想法向上彙報,領導們一邊非常支持,另一邊又有點擔心——萬一大張旗鼓參加測試,準備物料、機器,折騰一個遍,結果測試出來結果被 Oracle 八年前的分數吊打,螞蟻金服的臉往哪放??

這種感覺,頗像1840年大英帝國向清王朝宣戰前的心態——信心倒是有,但對面畢竟是叱吒風雲幾百年的老帝國,萬里發兵興師動眾,萬一真打不過可怎麼辦?

魯肅最終批覆,咱們先別搞十倍的,我們就做一個大小適中的 OceanBase——恰恰控制在 Oracle 得分的兩倍就行。

於是,項目正式立項。

中國公司參加 TPC-C 測試,在歷史上是頭一遭;分佈式資料庫參加 TPC-C 測試,更是史上第一次。

TPC-C 審計師在和 OceanBase 團隊交流。

至於測試用的硬體,因為 TPC-C 沒有特別限制,陽振坤選擇了劍走偏鋒——租用阿里雲。「分佈式資料庫」跑在「分佈式計算上」,相當朋克。

在阿里雲裡,210臺虛擬主機齊裝列陣組成地基,OceanBase 在其上如參天大樹盤根錯節,蔚為壯觀。用這種方式,陽振坤和老領導王堅跨越時空,相視一笑。

2019年8月,測試終於開始。TPC-C 的審計師特地從美國趕來杭州記錄測試過程。兩個月後,測試結果出爐。

螞蟻金服60880800分,正好是 Oracle 30249688的兩倍,沒控制太精準,比兩倍多一點點。。。

時隔九年,武林盟主終於易主

時隔九年,武林盟主終於易主。

OceanBase 打敗 Oracle,正如九年前 Oracle 打敗 IBM 。一代新人換舊人,歷史從來就是這樣輪迴。

TPC-C 測試不僅要看資料庫的絕對性能,還要看性能和成本的比值,也就是單位性能的成本。這個數值上,OceanBase 是6.25人民幣,Oracle 2010年的值是1.01美元,按照匯率來算,OceanBase 單位性能成本更低,這同樣要歸功於分佈式資料庫可以跑在成本低廉的雲計算上。

這下,OceanBase 終於可以慶祝了吧?並沒有。

在陽振坤心裡,這件事兒才完成了一半兒——說好了要超越 Oracle 十倍,少一分都不是十倍。

執拗至此,令人喟嘆。

於是在2020年,OceanBase 又馬不停蹄地開始了第二次測試,這次,1560臺虛擬主機在阿里雲中列陣,人類歷史上最大的分佈式資料庫矗立在賽博空間中。

第二次測試的過程恰逢全球新冠疫情,TPC-C 的審計師們也被迫在家辦公,通過網絡遠程監控 OceanBase 的數據。

漫長而灼心的等待。

自從2010年 OceanBase 誕生以來,這場等待已橫跨十年,漫長到最執著的看客都已經打起了哈欠,可是陽振坤他們還在咬牙前行。

如同一個人決定徒手爬上萬仞絕壁的那一刻,你就只剩下自己,你必須把所有他人的不解、嘲諷、鼓勵和祝福統統安放在山腳,唯一能帶到空中的,就是心跳。

2020年5月19日,跑分結果出爐,707351007。(注意,上一次是六千萬,這次是7億。)

OceanBase 火力全開,釋放天性,逆天地跑到了自己上一次分數的11.6倍,是 Oracle 2010年紀錄的23倍,單位性能的成本也猛降至3.98元人民幣。

至此,連最苛刻的人都要感嘆,OceanBase 正在把上個時代拋在身後。

TPC-C 網站上的排名再次刷新,Oracle 退居第三,僅僅是這一條跑分刷新,背後卻是技術人用五指扣緊石縫,十年間無人喝彩的「徒手攀巖」。

不過,無論陽振坤還是螞蟻金服都明白,跑分並不意味著一切。

資料庫的生態像一個花園,只有不同的人信任它,使用它,才會讓它變得豐富易用,成為數字世界的基石。在這個星球上,Oracle 的生態像一個龐大的熱帶雨林,它毫無疑問仍然是資料庫的王者。面對 Oracle 的「熱帶雨林」,OceanBase 的花園任重道遠。

大象仍在聚光燈下。

但螞蟻已經爬上舞臺。

OceanBase 團隊和彭蕾、

OceanBase 團隊和彭蕾、井賢棟。

(七)那些希望 

2020年,陽振坤55歲。每天晚上下班回到家大概十點半,他會換一套衣服,在小區裡快走半小時,大概3000米,如果下雨就換成室內走路,這是他堅持了22年的習慣。

OceanBase 團隊,從最初的一個人,到0.1版本時的20人,到1.0時的50人,到2.0時的100人,到如今所有人都在為 3.0 加班加點。十年難言順遂,容顏漸老,但大多數人都未離隊。

「有什麼東西支撐你們走下來嗎?」我問。

「集中式資料庫的技術已經走到了盡頭,我絲毫不懷疑在未來會有幾家公司打破「分佈式資料庫」的技術瓶頸。不過,目前我們是世界上唯一的那個。如果說這麼多年有東西在支撐著我,這就是理由。」陽振坤說。

數據是賽博世界的基石。你在淘寶上淘到的第一個寶貝,你存在餘額寶上的每一筆積蓄,那些你漸漸淡忘的過往和小祕密,資料庫都會幫你記得。

「我的祕密,要由我自己保管。」這是個樸素而簡單的價值觀。由此看來,一個屬於中國人自己的資料庫有更深遠的意義。

我問陽振坤:「你是不是一開始就想造出國產可控的資料庫?」

「沒有。」他斬釘截鐵。「我只是想做出來心中那個完美的分佈式資料庫。」

這個答案和我預想的不同,但我更喜歡他的答案。

最開始的時候初生牛犢不怕虎,我以為5年就能把 OceanBase 做個大概的。那時候知道資料庫這條路有這麼難,也許都不會開始了。其實直到今天,我們仍然把 Oracle 作為學習和追趕的對象。他們有太多積澱和閃光點。

陽振坤實話實說。

2020年,OceanBase 10歲。陽振坤距離退休還有正好5年,在他退休時,OceanBase 能否追上 Oracle 的腳步,還是個未知數。

「你退休後,OceanBase 怎麼辦?」我問。

「我會交給團隊的同學們,他們會比我優秀,會比我更愛 OceanBase。」他說。

OceanBase 同學們翻到了十年前的一張珍貴的照片,那時候大家都很年輕,相信一切。

我突然想到了魯迅寫自一百年前的《故鄉》。人心裡有「偶像」,無論真假,便能使人邁開腳步。只要出走,就會有路,遠方就在向你靠近。

告別陽振坤那天晚上,我做了一個有趣的夢。

兩個揹包的年輕人偶遇在鄉間小路。他們決定結伴同行。我坐在路邊的石頭上,實在猜不出他們各自的目的地是哪裡。於是我決定追上他們,走在他們身旁。

我並不著急發問,只是默默走著。

誰的目的地是下一個鎮子的酒吧,誰的目的地又是世界的盡頭,時間自會告訴我答案。

注:本文頭圖來自紀錄片《Free Solo》(徒手攀巖)

相關文章

像素時代的黃昏和「淘寶叛軍」

像素時代的黃昏和「淘寶叛軍」

淺友們好~我是史中,我的日常生活是開撩五湖四海的科技大牛,我會嘗試各種姿勢,把他們的無邊腦洞和溫情故事講給你聽。如果你想和我做朋友,不妨加微...

思科的沉浮往事

思科的沉浮往事

1973年,一個名叫萊昂納德·波薩克(Leonard Bosack)的小夥子從美國賓夕法尼亞大學順利畢業。 隨後,他加入了當時著名的計算機制...

思科,跌落神壇的行業標杆

思科,跌落神壇的行業標杆

1973年,一個名叫萊昂納德·波薩克(Leonard Bosack)的小夥子從美國賓夕法尼亞大學順利畢業。 隨後,他加入了當時著名的計算機制...