作者 | 趙之齊

編輯 | 胡敏

十一年前，阿里“雙十一”的備戰室里，國產自研分布式數據庫OceanBase的創始人陽振坤站在推開的窗邊，向時任螞蟻CEO的彭蕾“承諾”道：

“（OceanBase）出了問題，我們就準備從這跳下去。”

把自身與OceanBase成敗綁在一起的陽振坤，就是用這樣的決心，讓OceanBase從一個簡單的存儲系統，成長為國產數據庫的一大領頭產品，且通過TPC-C基準測試、擊敗連續九年位居榜首的Oracle。

一個多月前，2025年5月12日，OceanBase公司發送全員內部信，宣布陽振坤榮譽退休。

退休那天，這位60歲的程序員，依然沒有自己的獨立辦公室，也沒有助理。在日常工作中，他和年輕同事們一起在工位上看代碼，也自己貼發票報銷。

而此前一天，5月11日，正是他入職阿里的第十五周年，也是OceanBase誕生的第十五年。在向雷峰網 (公眾號：雷峰網) 回顧OceanBase的經歷時， 起初短短五六分鐘陳述里，陽振坤提了不下十次“困難” ，但好在，團隊最終還是證明了自身價值。

最初的困難是，怎么在集中式數據庫盛行的時代里，說服阿里高管投入大量財力與人力，做一款分布式數據庫。

而在獲得吳泳銘“給你兩年時間，證明OceanBase的可行性”的批準后，接踵而來的第二個困難是，怎么贏得各業務線的信任、用業務打磨OceanBase的能力，并在阿里內部證明其價值。

隨后，當OceanBase在阿里廣泛使用后，如何對外服務、創造更大的商業價值，又成了陽振坤的心頭重要事項。

重重挑戰過后，后來的故事人盡皆知：OceanBase成功了，不僅在技術上登頂世界，商業化的齒輪也運轉起來，2020年獨立為公司，2023年在金融行業營收規模2.7億人民幣，在金融行業本地部署市場中，份額第一。

OceanBase在技術與商業領域的雙線并進，是陽振坤帶領團隊在一個個考驗前做出的重要決策，也源自他銘記于心的恩師王選的教導：技術頂天、市場立地。

從國產數據庫不被看好的當年，到國產自研雨后春筍般爆發的如今，陽振坤帶領OceanBase的成長史，也是國產云數據庫發展15年的重要縮影。深耕計算機領域三十年的他，如何帶領OceanBase度過一個個難關？他和OceanBase互相成就的這一路，又有怎樣的故事？

陽振坤

堅持分布式的“夢想家”

Oracle九年來第一次痛失TPC-C基準測試榜首之位，就是敗給當時在公眾視野里還初出茅廬的OceanBase。

這個看似半路殺出的“程咬金”，從2010年起錘煉自身，已蟄伏等候此刻多時。其強大的產品實力背后，是陽振坤正確的判斷和團隊共同的堅持。

故事的開始，陽振坤做對的第一個決策是，在集中式數據庫盛行的年代，堅持分布式數據庫的道路。

這一切，可以從2010年說起。

2010年，陽振坤難得地給自己的人生放了一個月的假，陪陪家人，捋捋未來的計劃。就在當時，阿里的劉振飛向他遞出了橄欖枝。兩人此前在微軟一起共事，彼時劉振飛正負責淘寶的后臺系統運營管理。

陽振坤去了阿里面試，面試官是吳泳銘，他后來第一個直屬上司。2010年5月11日，陽振坤入職阿里，在基礎架構部門，職級是P11。有說法指，陽振坤加入淘寶后，本可以加入快速發展的淘寶業務團隊，主管技術，但糾結再三，他還是選擇并不那么好走的自研路子。

入職后大約一周，開發一款分布式數據庫的創想便逐漸成型。陽振坤向當時淘寶技術負責人吳泳銘提出這個想法。

深知數據庫成長需要周期的他，已感時不我待。但在集中式數據庫為主流的年代里，如何說服別人，給他這個沒有數據庫背景的人，一個嘗試做分布式數據庫的機會？

陽振坤給出的論點之一是，數據庫在集中式這條路上已經走到盡頭，接下來一定會往分布式走；且傳統單機數據庫缺乏擴展能力和高并發能力，對于離不開關系數據庫的互聯網來說，分布式數據庫“怎么看都是一件需要做的事”。

并且，當時阿里內部數據庫的數量高達6500個，大量的業務場景和數據需求令他心向往之，相信其中蘊含打磨出分布式數據庫產品的可能。

但，同樣不可或缺的，是身處“去IOE”（IBM小型機、Oracle數據庫和EMC存儲）節點上的阿里，提供的“地利”。

早期，阿里是Oracle在亞洲最大的客戶之一，Oracle會在官網上長期展示阿里的logo，阿里內部也有許多獲得Oracle認證的頂級工程師。

然而，2009年開始做“雙十一”的淘寶，數據量激增，讓Oracle已有些捉襟見肘：Oracle數據庫最多支持20個節點的共享模型，但阿里的數據量需要幾十萬臺服務器。阿里需要能力更強的數據庫。

后來阿里的成長速度，也證明這步預判是正確的：2009年成交金額只有大概5000多萬的“雙十一”業務，在2010年已達到9億多，到2019年有2600多億，呈幾千倍增長。2010年淘寶第二屆“雙十一”的平臺交易筆數每秒峰值就已經達到2500筆，但當時系統的極限容量是每秒3000筆訂單。有阿里內部人士透露， 2022年前后，在阿里內部使用的OceanBase、PolarDB和ADB數據庫系統共使用了約5萬臺服務器，已遠超Oracle的處理能力。

此外，從經濟利益上說，Oracle的授權費也過于昂貴，且運行時要依賴高端硬件設備。當時，阿里高層發現公司每年在IOE上的支出，呈現驚人的增長——小型機、高端存儲加上Oracle的各項費用，一套可能要兩千多萬，阿里每年要給IOE三家美國公司幾乎200億元采購費，這樣下去，阿里可能變成“給IOE打工”。

而立志要成為一家科技公司的阿里，也需要建立自身技術根基。 確定“去IOE”的戰略后的初期，阿里還想從已有的MySQL開源數據庫發力。但公司隨后意識到自研的重要性，在飛天系統、OceanBase數據庫等一系列技術根基建立過程中，也鍛煉了許多數據庫、中間件等相關研發人才，讓阿里云得以在2015年之前就打下技術和產品優勢，對其后來席卷云計算市場至關重要。

當時和陽振坤一樣相信分布式的，還有王堅——他是陽振坤在微軟的老板。陽振坤在2010年加入阿里后，有一段時間也向王堅匯報，在微軟時，兩人便已看好分布式的未來。而此前陽振坤在百度工作時，也深入學習了Google的分布式存儲和數據庫模型。在分布式的堅持上，他有底氣敢為人先。

想法有了雛形后，陽振坤隨后又花了兩周時間找客戶、再花了兩周在代碼上做簡單的原型論證。種種“天時地利人和”，加上早期阿里內部創新氛圍濃厚，吳泳銘也樂意授權各團隊自下而上搞創新，他提出的唯一要求是：兩年內證明這個項目的可行性。

至此，立項已成。那之后花了十多年長出累累碩果的OceanBase，起初的立項只花了六個星期。

與業務磨合：如履薄冰六七年

數據庫產品能力的提升，常面臨“先有雞還是先有蛋”的尷尬：沒有業務的磨煉，數據庫難以成長；但不夠成熟的數據庫，又難獲業務信任。

尤其在阿里內部， 業務線領導要自己背負業務指標，冒險把業務交給一個從0開始的自研項目，相當于自愿站到了懸崖邊上。

這一點，阿里云飛天系統的第一個客戶阿里金融已深有體會：當時深受折磨的阿里金融掌舵者胡曉明，便帶隊高管們，在2011年12月31日晚上來到阿里云，向阿里云高層們鞠下無言的一躬，以求過一個不被飛天報警鈴聲打擾的安穩的春節。（無言鞠躬背后如何風云暗涌？歡迎添加作者微信 Ericazhao23 了解）

有了這一“前車之鑒”，各業務線對新技術的加倍謹慎自不必說。攻略業務線的老大，是從淘寶內部成長起來的OceanBase，避無可避的難關。

陽振坤自然擔起這一重任?；仡櫘敃r，他笑說自己“好像個大齡推銷員”，對淘寶內部的業務技術團隊逐個登門拜訪，“推銷”到口都干了之后，終于遇到一個愿意嘗試的項目：淘寶收藏夾。

之所以有機會，是因為當時淘寶收藏夾面對的性能瓶頸，內部還沒有別的辦法解決——

用戶每次打開收藏夾時，系統都要檢查商品價格、在線情況等狀態變化，因此，數據庫就要頻繁訪問硬盤數據。如果很多用戶同時訪問收藏夾，數據庫的計算量和I/O需求就會大幅增長。要是訪問硬盤上100個不同的位置，就要讀取100個不同的“塊”（Block），每讀一個塊可能需要1毫秒，用戶打開讀取淘寶收藏夾的速度就會變得非常慢。

然而，如何讓業務團隊相信，初生的OceanBase能解決這個問題？

“數據庫只要出一次問題，就永遠沒有信用，哪怕會給業務帶來好處，也沒有人敢用了”，陽振坤向雷峰網說道。在他眼中，業務團隊給出的每一次磨合機會，都是不可失手的關鍵戰役。

深諳此理，陽振坤帶著滿滿誠意和一套切實的解決方案，拜訪了淘寶收藏夾的主管魏虎。

他首先向魏虎闡述了自己的觀察：淘寶收藏夾大部分數據的特點是，數據總量大，但每天的修改量很小。因此，可以嘗試把每天業務低谷期（如凌晨兩點之后）修改的數據，先放在內存里，到下一個低谷期（例如兩點）時，再把當日修改跟原來的數據做大合并寫回去。

但這一切變化只發生在后臺，作為用戶，在前端依然可以實時看到更新。

要了解這個做法的創新，就要先了解硬盤和內存的區別：硬盤中的數據需要基于“塊”的方式讀取、順序訪問，即便只需要讀取其中一條記錄，也要把整個塊讀取出來后再找到需要的記錄，早期硬盤中，一個塊的大小通常為512字節。而內存則能隨機訪問設備，可以直接訪問任意一個字節的數據，速度更快。

假設用戶收藏的100件商品存在多個不同的定常塊里，原來的方法，只要用戶有修改，就得把硬盤里這個塊讀出來，在內存改好后寫回去，下個客戶來讀，又得從硬盤上檢查每個塊的修改情況。而新的方法中， 修改都存在內存里，當用戶訪問時，只需快速訪問內存了解數據修改的情況，并和原來的數據合并，給用戶展示。

兩種操作的核心區別是： 減少大量重復的動作 ，大力提升收藏夾運行的效率。

這個方案俘獲了淘寶收藏夾團隊們的心。在他們的催促下，陽振坤團隊開始了驗證測試。

團隊在兩個月左右進行簡單版本的測試，驗證可行；再花六個月完成第一個正式版本，在生產環境中試運行。試運行四個月后，方案正式投產。前前后后，花了將近一年時間。

而運行OceanBase之后的淘寶收藏夾，從原需32臺服務器，減到了14臺，其中，12臺處理靜態數據，2臺負責動態數據。

淘寶收藏夾和OceanBase的這場相遇，可以說是一場雙向救贖。從此，OceanBase站上了數據庫產品的起跑線，而直到今天，淘寶收藏夾仍是OceanBase的用戶。

然而，OceanBase確實也只是剛剛站上了起跑線，陽振坤直言， 當時數據庫的功能“連1%都沒做好” 。

他開始在內部尋找第二個大型業務。

陽振坤曾將目光投向淘寶購物車，但購物車對淘寶而言是幾乎不可容錯的核心部分，謹慎定奪后，他還是沒有邁出這一步。

那一年里，他依然跑遍了業務部門，但沒能幸運地獲得第二個像淘寶收藏夾一樣具有代表性的業務。永遠卡住的一個環節是：如何向業務部門展示OceanBase的價值。

他們在忙忙碌碌中度過了第二年， 2012年秋天，本該是收獲的季節，但OceanBase再也找不到新的業務，項目面臨關閉風險 。即便是CTO吳泳銘，也難以直接干涉業務部門的產品使用抉擇，對此愛莫能助。

就在此時，王堅牽線，建議他們去到如火如荼開展“去IOE”的支付寶。

兩年期限臨近的關頭，陽振坤果斷抓住這次“復活”機會，帶著OceanBase團隊，在2012年11月15日來到支付寶。

彼時，馮春培（花名孔丘）和程立（花名魯肅）等人已經解決了穩定性的問題，讓支付寶實現100%的運維可用率。需要解決的新問題是：大量使用Oracle數據庫的支付寶，如何降低軟硬件的成本？

當時，支付寶嘗試給出的打法是用MySQL+普通PC機替代。然而，普通PC機的故障率遠高于IBM小型機和EMC存儲，會讓系統的可用性顯著下降。

這個扔到陽振坤面前的難題，并非一塊好啃的骨頭：淘寶的數據庫出問題，最多只是用戶暫時無法購物，可以通過工作人員的及時修復和誠懇道歉重獲用戶支持；但在支付寶的“錢”上出問題，失去的用戶信任將無可挽回。

就連當時非?？春迷植际綌祿烨熬暗闹Ц秾欳TO魯肅，也問過陽振坤：“你如何保證OceanBase不弄丟支付寶用戶的一分錢？”

陽振坤被這個問題問懵了。但他接下挑戰，帶著團隊探索新的方法。

魯肅這個問題背后的邏輯是： 如何在降低硬件成本的同時保持系統穩定性？ 幾經摸索后，陽振坤團隊引入了Paxos協議技術：讓一筆交易用三臺機器做，只要有兩臺機器成功完成，這件事就做成了。這筆賬可以這樣算：一臺PC機出故障的概率如果是千分之一，兩臺同時壞的概率可能就是百萬分之一，三臺則是十億分之一。

這一技術的變革，也是對員工的解放：以前只要主庫壞了，不管幾點，大家就要幾分鐘內起來做人工對賬，但現在，只要有一兩臺機器繼續工作，系統就能繼續運行。能睡上安穩覺，這也一定程度“收買”了業務團隊的心。

后來，騰訊、華為等公司在基于MySQL的系統中，也都采用了類似技術。

2014年，OceanBase 0.5版本已經做到“半分布式”系統： 所有數據修改都在同一臺機器上進行，但讀取數據時使用多臺機器 。并且，其在關系數據庫系統上做到單機/單機房故障不丟數據、不停服務，也已經超過了國家標準。

但， 三年沒有新標桿業務的OceanBase，還是難以避免地開始受到質疑。

要么成功，要么沉寂。種種壓力下，陽振坤把賭注，押在了阿里技術人每年的“大考”上：“雙十一”。

他向魯肅自薦用OceanBase替代Oracle，但業務團隊并不接招，于是，魯肅出面，把相關負責人叫過來一起談：

“OceanBase有什么問題，大家具體指出來，不要說‘感覺不穩定、害怕出問題’這些虛的?！?/p>

陽振坤還給時任螞蟻集團的CEO彭蕾寫了封郵件，大力推薦團隊產品：“咱們的同學非常優秀：給他們一個信任，他們會給我們驚喜甚至奇跡，我們認為技術上做不到的，他們也能做到……”

經歷長達半年的切磋談判，最終，OceanBase爭取到了1%的流量測試機會。

命運眷顧有心人，就在那年，Oracle無意中也給OceanBase的成長“推波助瀾”：在“雙十一”前夕的壓力測試中，數據量一上到90%，Oracle就報錯崩潰。情急之下，業務團隊只好找到陽振坤：“給你們10%行不行？”

團隊喜出望外，臨危受命。

“雙十一”流量的10%，基本就是淘寶平時100%的流量。OceanBase能否承住這份壓力？眾人矚目下，就有了2014年OceanBase“雙十一”作戰室里的名場面：

當晚，時任螞蟻集團CEO的彭蕾鼓勵團隊之際，也詢問緊張備戰的團隊們：“有沒有信心？”

恰好站在窗邊的陽振坤，推開了窗，摸不出幾分玩笑幾分真，只是說道：

“出了問題，我們準備從這跳下去?！?/p>

所幸，OceanBase順利地度過了雙十一，在全場的掌聲中，陽振坤心知這背水一戰終是成了。一戰成名，OceanBase逐漸接下了大淘寶100%的流量。

在這之后，團隊繼續實現起初打造分布式數據庫的承諾。

如前所說，當時的OceanBase還是“半分布式”系統：只是寫入一個單點，讓所有數據的修改在同一個點上，避免復雜性。在陽振坤看來，這種做法短時間內能支撐支付寶的交易需求，長遠來看不可持續。

2014年9月之后，團隊開始將其升級為完全的分布式數據庫系統——每個節點都可以再做修改，節點與節點之間平等，沒有什么特殊。

這步升級，花了整整兩年時間。

直到2016年初，OceanBase系統開始替換支付寶最核心的賬目系統中的Oracle數據庫。這之后，完成所有項目的替換只是時間問題，“最困難的部分已經完成了”，陽振坤感慨。

產品能力逐漸成型后，他開始把眼光放到外部商業化上。

內外“交困”：費口舌不如跑分

“在公司里做一件事，你終究得證明自己有價值”，陽振坤向雷峰網說道。

在大廠中成長起來的數據庫，一個天然的可得優勢是，能用公司內部成熟的業務磨練產品。然而，這塊硬幣的另一面是， 需要把握“滿足業務團隊高定制化需求”與“打磨自身數據庫產品通用能力”之間的平衡。技術團隊與業務團隊的期望，常常出現巨大鴻溝 。

并且，2016年前后，OceanBase還受到過阿里內部其他數據庫的挑戰，經歷了一場“華山論劍”：嬴者才有繼續做數據庫的權利。（更多幕后故事，歡迎添加作者微信 Ericazhao23 交流）

鏖戰過后，各方打平。盡管如此，OceanBase這個數據庫老大哥或許也進一步意識到，是時候走出阿里這個“舒適區”了。

為了更好提升數據庫功能，為了一定程度上保持OceanBase的自主性，也為了證明數據庫產品的價值，2016年底，陽振坤開始帶隊做外部業務。

2017年，OceanBase獲得了第一個外部客戶，南京銀行，也是互聯網金融相關業務。

但早期獲客舉步維艱，2020年前后國產數據庫賽道在卷的“自研”，此前在用戶眼中是“不靠譜”的代名詞。彼時OceanBase名氣不足，質疑聲多得團隊成員的耳朵都快被磨出繭子：

中國的數據庫領域已經發展了幾十年，但還沒有哪個數據庫真正做得成功，你們怎么就成功了？Oracle這么多年都沒做出分布式數據庫，你們怎么可能做出來？

當時團隊規模也就百十來人，“百”口莫辯之時，陽振坤做了一個決定：跑分。

數據庫也有自己的全球性能排行榜，若能登榜，OceanBase的能力不證自明。但這并不容易， 至少在當時，中國還沒有數據庫能通過TPC-C基準測試，而Oracle已經穩坐第一名的位置，九年。

初生牛犢不怕虎的OceanBase，在2018年報名參加了這項測試，開始打榜。經歷長達一年審核后，2019年10月2日，結果公布：OceanBase通過了測試，擊敗Oracle登頂。

至此，OceanBase這個既能做交易、也能做分析的HTAP數據庫新星，在公眾視野中冉冉升起。螞蟻高層也正式決定，OceanBase作為一個單獨的公司獨立運營。

下一個重要的決策，是 開源 。2020年6月正式成立的OceanBase公司，9月開始進行文檔代碼整理，在第二年6月正式開源。開源尚未成為主流的當時，把數據庫開成“白盒子”，也是陽振坤團隊為消除客戶不信任感和陌生感的努力。

但OceanBase的成長并未就此停下。

生長于阿里的OceanBase，為大客戶量身定制，起初開拓的外部客戶，如南京銀行，業務量也很大。但隨著接觸企業范圍擴大，陽振坤觀察到，中小型用戶的五十個業務里，可能只有兩三個業務單機系統做不了、需要分布式，若一概使用分布式系統，對他們來說成本過高。因此，OceanBase也開始針對中小客戶的需求優化， 提出“單機分布式一體化”概念 。

通俗點講，就是讓分布式和單機系統同時存在，企業可以把規模小的業務用單機系統跑，業務量擴大時再疊加更多機器。這種系統在高配置和低配置下都保持不錯性能的打法，避免“用高射炮打蚊子”，但要求團隊付出更多精力技術調優。

陽振坤常掛在嘴邊的一句話，是他的恩師王選的重要教導：“頂天立地”。拆開來講是，技術頂天、市場立地。

也因此，他對OceanBase的發展規劃，并不局限在技術層面的提升，而是積極走進市場、在市場的檢測下調整優化。這也是OceanBase突破重重難關，獲得今日成功背后的邏輯。

2006年在百度就開始追隨陽振坤腳步的楊傳輝，現在是OceanBase的CTO，他感慨：“如果一個問題，陽老師想了好多天還是無解，那這個問題肯定無解，因為有解的話，他一定能想到解決辦法?！?/p>

職業生涯中，三次“重啟人生”

時間來到2025年5月12日，陽振坤榮譽退休?；仡^看，30多年前，站在王選辦公室外忐忑的那個24歲年輕人，或許也難以想象，自己那天敲開的通往計算機研究所的大門，會指向一個如此瑰麗又廣闊的未來。

1989年春天，在北京大學計算機研究所實驗室隔斷出來的一個小隔間里，陽振坤第一次見到了王選。在這個簡樸的辦公室里，修完大學課程只用了三年、碩士只用了一年多的陽振坤，向王選表達說，希望能成為他的學生。

王選的一個允諾，讓陽振坤跟著他做了13年的激光照排。那是他人生第一次轉變賽道、重啟。1995年，陽振坤所在的團隊獲得國家科技進步一等獎，1997年，32歲的他被破格晉升為教授。

2002年，互聯網發展迅速，抱著對社會第一線工作的好奇，陽振坤離開了大學，在36歲闖入工業界，開始第二場新的嘗試。他去到聯想研究院擔任首席研究員，負責無線通信領域的研究；后來又接觸分布式系統，在微軟亞研、百度從事相關工作。

陽振坤來到百度是在2006年。他最先學習了Google開發的兩種分布式存儲和數據庫模型，Bigtable和Spnaner， 并用C和C++寫了一套鳳巢系統，基本類似于2009年阿里做的ODPS系統 。當時國內幾乎還沒有人做類似項目，團隊對這個方向都信心滿滿。

在團隊成員的記憶中， 那時出去講分布式系統的概念，就像現在和別人講量子計算，聽者都一頭霧水。

然而，兩年一過，這個項目就被放棄了——因其兩年內還不能在核心業務應用，被認為不能主力投入。

后來在阿里的經歷則比較幸運。兩年的時間窗口里，陽振坤不需要背負KPI，得以專心研發，鍛造出職業生涯中最恢弘也是最辛苦的項目，OceanBase。能把這個項目做成，繞不開的，是陽振坤奠定下的極客基因。

在面試新人的過程中，陽振坤常常會拿出一張紙，給面試者畫OceanBase的框架圖，像布道者。也有OceanBase內部人員評價，陽振坤追求做出“面向未來的東西”，要更強壯、更有擴展性。因此，只要精力足夠，做得不夠好的部分，團隊總會不斷推掉、重來。

互聯網大部分項目周期是兩周，但數據庫的發展沒有三五年，往往也難以真正落地。內部業務催得緊，有時連團隊內部成員也頗有微詞。與時間進行毫無懸念的賽跑時，陽振坤也常需要安撫人心。曾有新加入團隊的年輕人向陽振坤抱怨說，合租的室友在天貓工作，做網頁熬一兩周就看到成果了，但自己的付出卻好像離收獲遙遙無期。

對此，陽振坤給出的回答是：“再過三年，你做的數據庫天貓還在用，但他改的網頁早就看不到了”。

做學問出身的陽振坤，對產品本身之專一，令他對這之外的一切，包括管理，都不買賬。種種光環下，他依然維持最簡單的一面示人。有客戶對他印象最深刻的，是會面時穿著涼鞋的形象。團隊成員們有時會笑評：“60歲的科學家，像個農民一樣。”

九十年代時，陽振坤曾跟著王選去美國，在IBM的研究中心里，他看到很多程序員即使白發蒼蒼，也依然坐在辦公室，敲鍵盤寫代碼。

那是陽振坤心目中程序員應該有的樣子。

國產數據庫起步最艱辛卻也滿懷希望的過去十多年里，陽振坤一直坐在他的辦公桌前，日復一日地面對那些視如己出的代碼。年過花甲的他，已悄然將自己活成那幅畫面中的一部分。

作者持續關注云計算、數據庫、AI等相關領域，歡迎添加微信 Ericazhao23 交流。

雷峰網原創文章，未經授權禁止轉載。詳情見 轉載須知 。