導語：誰能想到，一個本科和碩士都在鑽研數學的人，會在後來做出世界上第一款原生分散式資料庫？在2010年以前，陽振坤自己也想不到會有一天和資料庫建立如此密切的關係，更想不到，往後十年是他職業生涯中非常艱難的十年。
採訪者/作者：田瑋靖
受訪者：陽振坤，OceanBase分散式關聯式資料庫創始人
“如果進不去，我們就錯過了支付寶“去O”的機會，那麼OceanBase再也沒有機會了。”
面對採訪鏡頭，陽振坤淡然地訴說著那場生死之戰。而他口中的OceanBase資料庫，是從出生就不被看好的“孩子”，曾幾度站在生死邊緣。
不做工程，紙上談兵
生於1965年的陽振坤，不能完全說他和大多數人一樣。一樣的是小升初、初升高的學習軌跡，不一樣的是，他在1984年考上了北京大學。20世紀80年代，大學有多難考？據歷年高考資料統計顯示，1984年參加高考的人數為164萬，錄取人數為48萬人，錄取率29%。表面看，錄取率不低，實則僅約佔同齡人的0.0179（據歷年出生人口資料，1965年出生人口為2679萬人）。相當於100個人裡，只有1個人能考上大學，在那個大多數人只能維持溫飽的年代，又有很多人因為交不起學費而放棄學業。因此，能夠上高中已是“百裡挑一”，考上大學更是被稱為“天之驕子”。在本科和碩士研究生期間，陽振坤不僅鑽研數學，也學習了很多計算機的基礎課程，研二參與了北大計算機研究所的專案研發。興趣使然，他在博士研究生期間，選擇了計算機方向。畢業後留校任教，並被破格提升為副教授、教授，時年32歲。
事業順風順水之際，陽振坤選擇離開學術界，進入產業界。或許是受其博士導師王選院士（中國科學院院士，中國工程院院士，計算機漢字鐳射照排技術創始人）的影響，陽振坤覺得“不做工程，等於紙上談兵”。其先後任職於聯想研究院 、微軟亞洲研究院、百度等。
到此為止，陽振坤的前45年，都跟資料庫搭不上邊。
做一個“大飛機”
彼時的百度、阿里巴巴、騰訊（俗稱“BAT”）這三大網際網路巨頭，只有阿里巴巴（以下簡稱阿里）看好雲端計算。陽振坤作為雲端計算方面的專家，是阿里急需的高階人才。在阿里合夥人劉振飛的邀請下，陽振坤於2010年 5月12日加盟淘寶網。從淘寶網的內部任命郵件中，足以見得其對陽振坤的愛重：“陽博士是我們期待已久的人才，在系統設計和實現、海量資訊處理、演算法設計等諸多方面都有著非常豐富的經驗。深信陽博士和團隊通力合作，一定能為淘寶網打造一個高效能、高可靠、低成本、面向大流量大規模電子商務的專用計算平臺，為支撐‘十億消費者，十萬億交易額’提供所需要的基礎技術。”
可他偏偏放著似錦前程，選擇了一條最艱難的路——自研分散式資料庫。
其實，早在微軟亞洲研究院工作時，陽振坤結識瞭如今的阿里雲創始人王堅，並接觸了分散式系統，二人都非常看好分散式系統。進入淘寶之前，陽振坤在家待了一個月，期間就在思考下一步要做事情。用他的話說，“當時有一個大致的思考，到淘寶也不確定能不能做這件事，但是有機會。”
彼時，集中式資料庫獨霸天下，代表產品如美國甲骨文公司的Oracle資料庫，更是獨領國際市場，阿里便是其在中國最大的客戶。而網際網路的廣泛商用、雲端計算、大資料、物聯網、區塊鏈、人工智慧等技術的興起，加速了移動網際網路的到來。在人與人更便捷的互聯互通、社會更加智慧化的背後，是對業務系統越來越頻繁的併發訪問、越來越龐大的資料處理量。集中式資料庫昂貴的成本及其儲存和計算極為有限的擴充套件能力都顯得捉襟見肘。
集中式資料庫的本質是單機資料庫，在網際網路日均流量上百億破千億的環境下，單機資料庫的儲存能力都極其有限，更談不上如何分析、處理資料。受限於分散式資料庫更加複雜、故障定位更加困難、分散式事務效能有所降低、系統成熟度有所不足等因素，傳統資料庫廠商選擇了“分庫分表+中介軟體”的解決方案，即基於集中式資料庫，對業務進行較大幅度地改造和拆解、拆分，使每個拆解、拆分後的部分適合於單個集中式資料庫，這就是分庫分表資料庫。這種方式其實是把原來在一個資料庫中的大業務拆分為多份小業務，陽振坤稱之為“沒有大飛機，就分成多份，用小飛機來運”，但如果是重灌備、重武器如坦克大炮，小飛機裝都裝不下。因此，這終究不是徹底解決問題的辦法，而且面臨高額的成本和繁雜的運維。
陽振坤意識到“機會來了！”於是立項，“方向和目標是明確的”。儘管分散式聯機事務處理的開發非常複雜和困難；儘管分散式資料庫在SQL優化器、儲存架構等方面門檻極高；儘管這個分散式資料庫需要長時間的、大量的實際場景打磨；儘管分散式架構與關係型資料庫結合，沒有任何可參考的先人經驗，
“我們要做一個大飛機，不管你有多大的業務量，都能用分散式資料庫這個大飛機給你運走”。當系統容量不受限制的時候，一定能做更多的事情。這是陽振坤當時唯一確定的事——價值。
陽振坤的做事方式是“把事情想清楚再做，做到哪算哪就麻煩大了”，只確定目標，如何行動依然是問題。好在做分散式資料庫需要哪些功能，其實不用發愁，有現成的如MySQL、Oracle等成熟的開源和商業資料庫，功能早就定義好了。也就是說，建立分散式的環境，用多臺機器，參考成熟資料庫已有的功能列表，實現分散式資料庫。
但對於資料庫這種基礎軟體而言，尤其是與傳統集中式資料庫架構完全不同的、新型的分散式資料庫，絕不是把架構搭建好、程式碼寫出來就能應用在業務中的。而是得從一個個具體的業務開始，針對它做基礎功能，滿足其基本業務需求，然後一步一步將資料庫做大、做強。因此，只有找到業務需求帶來的機會，切入進去，並且落地，就有機會活下來。
一定要“活下來”
說起來容易，做起來難，陽振坤要做的分散式資料庫，是個“難產兒”，根本找不到業務。
好在當時出任OceanBase專案負責人的楚材是淘寶老人，他帶著陽振坤走遍了淘寶各個業務技術團隊，幾天後，終於在淘寶收藏夾這個業務團隊找到一絲的機會。
為什麼淘寶收藏夾願意試水？“收藏夾是一個比較特殊的需求，到現在為止，我們也不知道有什麼更好的方案能解決它的問題。”收藏夾給淘寶使用者提供的服務是，一個人可以收藏上百條、上千條自己感興趣的商品，商品的資訊變化如降價、下架等都需要及時更新，以便使用者掌握商品動態。每次使用者開啟收藏夾，後臺系統都要查詢資料庫成百上千次，獲取每個商品的最新資訊，這對於資料庫來說，相當於幾百萬、幾千萬的人在讀取資料，再乘百千次的讀次數。如此高頻的資料處理量，幾乎沒有什麼資料庫能夠扛得住，經常被使用者投訴“沒反應”“打不開”。
“我們做了一個比較特殊的架構，後來發現這個架構有非常大的價值”，陽振坤欣喜地說道。簡單來講，商品資訊修改不會直接寫進硬碟，而是暫存在記憶體中，每次使用者收藏夾展示的時候，只需要從記憶體中獲得修改後的商品資訊。相當於將收藏夾原來的成百上千次I/O（輸入/輸出）變成了一次I/O，原計劃需要擴容至數百臺機器，現在也只需20多臺機器就能解決問題。這極大地減少了機器數量，降低了成本，增強了業務穩定性，初步證明了OceanBase的生存價值。然而，好景不長，在2011年收藏夾上線之後，整個2012年OceanBase都沒有找到第二個價值如此顯著的業務。陽振坤直言“2012年真有點做不下去了。”
因此，2012年的唯一目標就是，活下來。
頂著團隊隨時可能解散的壓力，陽振坤找到時任阿里巴巴首席架構師的王堅，吐露難處。而後經王堅推薦，在2012年11月15日，OceanBase團隊從淘寶調到支付寶。因為支付寶業務是跟錢打交道，對資料的一致性要求更高，所以希望在支付寶業務找到機會。陽振坤知道“如果在支付寶再找不到機會，就完蛋了。” 在“人生地不熟”的新團隊，他們一邊熟悉人，一邊摸索生的機會。
幸運的是，OceanBase團隊遇到了一位開明的領導人，時任支付寶技術負責人的程立（花名魯肅，現任阿里集團CTO），他對新技術持鼓勵、支援的態度。恰逢七、八月份的時候，支付寶開始討論怎樣“去O”，即替換Oracle資料庫（早在2009年，阿里巴巴就提出了“去O”）。但面臨的極大難點在於，如果不用Oracle資料庫，不用共享儲存，選擇類似MySQL這樣單機資料庫，資料丟了怎麼辦？在金融領域，這是無法接受的後果。而繼續使用Oracle資料庫，對於業務資料量、資料併發量都巨大的阿里業務，所要付出的軟、硬體成本是無法估量的高昂。
陽振坤胸有成竹地說“我們有辦法解決這個事”。這個辦法就是如今被廣泛應用的三副本，每一筆事務在3個節點或者5個節點上同時做，超過半數成功即認為成功。舉個例子，三臺機器中壞掉一臺機器，剩下兩臺機器至少有一臺機器的資料是正確的，以此方法解決替換Oracle的核心問題，即放棄共享儲存之後資料損壞、丟失的問題。
OceanBase 0.5版本由此誕生，也為OceanBase開闢了一條生路。
但陽振坤明白，這只是給了OceanBase一個證明自己的機會。從提出解決方案，到0.5版本正式釋出，用了7個月左右的時間。另一邊，業務團隊卻很難一下子接受OceanBase資料庫。首先，這個版本沒有經過其它業務的驗證就應用到核心業務，是否可行？讓OceanBase資料庫支撐支付寶的交易庫，處理交易流水資料，業務團隊很難放心。其次，OceanBase技術方案要求三個機房，需要在原有的主、備機房的基礎上，再增加一個機房，而當時除了杭州，阿里和支付寶在其他城市都沒有三個或以上的機房。
為此，雙方几次三番激烈地爭論。對於OceanBase資料庫來講，這是一個生死之戰，如果不抓住這次落地機會，不僅是錯過支付寶“去O”的歷史性機會這麼簡單，而是OceanBase資料庫再也沒有機會了。所以OceanBase團隊當然是極力爭取，另一邊，業務團隊也保持非常謹慎的態度，雙方僵持不下。
最後還是魯肅出面說服業務團隊，便有了OceanBase資料庫分流1%的機會，如果出問題，1%的流量會被隨時切走。回想此事，陽振坤的態度是“我們的運氣不錯”。2014年“雙11”前，大抵是9月底或10月初，業務團隊開始為“雙11”的支撐做壓測，由於流量非常大，已經超出Oracle資料庫的預定容量，超出系統的I/O能力，系統大量報錯。
由於時間緊張，臨時買裝置，手提肩扛伺服器再次擴容已經來不及。業務團隊想起壓測時支撐1%流量的OceanBase資料庫，找到陽振坤說“給你們10%的流量能不能撐得住？”OceanBase團隊當然高興了：“別說10%，就是100%都可以支撐得下來”。甚至在“雙11”當晚的作戰室，面對時任螞蟻金服CEO彭蕾（現任螞蟻集團董事長）的擔憂，陽振坤說出了不成功就跳窗的玩笑話。
結果很順利，這一戰也基本確定了OceanBase資料庫在支付寶的地位。用OceanBase資料庫替代Oracle資料庫之後，單副本資料可以做到原來的1/7，其計算資源投入也降低為原來的1/12，僅儲存一項，就比Oracle資料庫節省了約20億元，相當於每賬戶成本節省了90%。
此後的路便順風順水，2015年替換Oracle資料庫支撐支付寶的支付系統；2016年OceanBase 1.0版本釋出，由原來的半分散式資料庫升級為真正的分散式資料庫，並於同年替換Oracle資料庫支撐支付寶的賬務系統，實現了螞蟻集團的“去O”目標；2017年走出螞蟻集團，對外商用。
而在對外商用之前，陽振坤要回答一個很關鍵的問題，別人為什麼一定要用OceanBase資料庫？
正如前文所述，大飛機比小飛機有價值，但如果別人有小飛機就夠用了，憑什麼花費工夫替換一個大飛機？
利益是永恆不變的，對於一個初出茅廬的新事物，只有提供足夠的價值，才能生存。目前絕大部分的資料庫產品分為交易系統和分析系統，兩套系統的體量和成本都是巨大的。在業務場景中，兩套系統往往也會有延遲。如果用一套資料庫，既做交易處理，又做分析處理，就能解決成本和實時同步的問題。陽振坤非常確定，“如果這件事情做成了，極有可能是對整個行業的顛覆，而且這件事情肯定可以做成。”這便是後來引發行業熱議的HTAP（Hybrid Transactional and Analytical Process，一體化事務和分析處理）。
未來取決於此
都說不被看好的孩子反而更有出息，2019年，OceanBase資料庫打破Oracle資料庫保持了9年的TPC-C（線上事務處理基準測試）世界紀錄，成為中國首個登頂該榜單的中國資料庫產品；2020年，OceanBase資料庫再次創下7.07億TPC-C的效能記錄，牢牢佔據了榜首位置；2021年以1526萬QphH的效能打破TPC-H（資料分析型基準測試）世界紀錄（目前排名第二）；同年OceanBase資料庫在螞蟻集團的支援下，宣佈成立北京奧星貝斯科技有限公司，並再次開源。
為什麼是“再次開源”？早在2011年，OceanBase 0.2版本就已開源，但在0.4版本後，OceanBase資料庫開源中斷了更新。這是因為從當時螞蟻集團的視角看，OceanBase資料庫主要是支撐螞蟻集團內部的業務，為淘寶、天貓、支付寶等業務服務，OceanBase團隊忙於“活下來”而無暇開源事務，所以2013年後， OceanBase資料庫開源停止了更新。直到2021年，擺脫所有顧慮的OceanBase更加堅定地擁抱開源，將儲存引擎、SQL引擎、分散式引擎、分散式事務、多副本、高效能、擴充套件能力、優化器、故障恢復、多活容災等核心技術及程式碼對外開源分享。
面對業界對其開源動機的聲聲質疑，陽振坤在《曾被“霸凌”的兩個孩子：電動汽車與分散式資料庫》一文中，引用《矽谷鋼鐵俠》這本書中對馬斯克開放特斯拉專利的描述，借喻OceanBase開源系統核心的原因。“當馬斯克在2014年宣佈特斯拉將公開其所有專利時，分析師們試圖確定他是不是在作秀或者其中是否隱藏了不明動機或者圈套。但馬斯克的決定就是這麼坦率，他希望人們製造併購買電動車。馬斯克認為，人類的未來取決於此。如果公開特斯拉的專利意味著其他公司能夠更容易地製造出電動車，那麼這對人類來說是有利的，這些理念應該是免費的。憤世嫉俗的人一定會嘲笑他的觀點，但馬斯克已經計劃好這麼做，他在解釋自己的想法時是真誠的，而且極為真誠。”
顯然，陽振坤認為，原生分散式資料庫是資料庫發展的必然選擇，資料實時處理的未來取決於此。陽振坤也希望出現更多真正的分散式資料庫產品，這從國產資料庫的角度，有望實現“去IOE”，讓更多中國資料庫走向國際市場，站在更高的角度，這對資料庫生態的發展和科技的進步是有利的。
尾聲
如今，OceanBase資料庫已積累400多個外部企業客戶，涵蓋銀行、證券、能源、電力、社保等眾多重要行業，且沒有一家企業後悔使用OceanBase，想換掉它，即便OceanBase用一套系統進行交易和分析處理的功能還在走向成熟。
陽振坤實現了他多年的目標——做一款真正的分散式資料庫。
當被問到職業生涯中，做OceanBase資料庫是不是最難熬的，以及團隊面臨解散是否想過放棄時，陽振坤的回答讓我們看到了他的堅韌。“是比較難熬，很多時候，你不能把握自己的命運，你知道一件事情是對的，但你想讓其他人相信它，是很難的。所以做OceanBase資料庫的過程中，我認準一點，只要這個專案沒有被‘槍斃’，我們就做，放棄也沒好處對吧？如果有一天被‘槍斃’了，我們也沒招對吧？反正只要能做下去，我們就做下去。”
本文為《新程式設計師004》內容，與OceanBase創始人陽振坤暢談他的程式人生。《新程式設計師004》即將上市，敬請期待。從MySQL之父、MariaDB創始人 Michael “Monty” Widenius，到PostgreSQL全球開發組聯合創始人Bruce Momjian、阿里巴巴副總裁賈揚清、指令集創始人兼 CEO潘愛民、著名科技作者吳軍，再到 Vue.js 作者尤雨溪……《新程式設計師004》以「我們的技術時代，我的程式人生」為主題，與多位國內外知名的技術先鋒和新生代程式設計師代表進行了深度對話，希望行業優秀人物的技術之路與人生感悟給大家帶來啟發。
————————————————
版權宣告：本文為CSDN博主「《新程式設計師》編輯部」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/program...