厲害了，螞蟻金服！創造了中國自己的資料庫 OceanBase

關鍵時刻，第一時間送達！

2008 年，王堅從微軟亞洲研究院常務副院長的位置上離職後，於當年 9 月加入了阿里巴巴集團擔任首席架構師一職，負責集團技術架構以及基礎技術平台建設。加入阿里沒多久後，王堅就提出了「去 IOE」的想法，即擺脫過去 IT 系統中對 IBM 小型機、Oracle 資料庫以及 EMC 存儲的過度依賴。

2009 年開始，阿里舉全公司之力投入到雲計算的研發和使用中，這可視為取代 IOE 之舉。2010 年，陽振坤加入了阿里，這位在 1999 年就成為北京大學首批長江學者、曾獲得國家科技進步一等獎、先後擔任北京大學計算機科學技術研究所副所長、聯想研究院首席研究員、微軟亞洲研究院主任研究員、百度高級科學家等職務的研究員，帶領團隊在阿里做出來了取代商業資料庫的 OceanBase。

2013 年 5 月，阿里集團最後一台 IBM 小機在支付寶下線。2013 年 7 月，淘寶廣告系統使用的 Oracle 資料庫下線，也是整個淘寶最後一個 Oracle 資料庫。2014 年，OceanBase 替換了支付寶交易系統中的 Oracle 資料庫。2015 年，OceanBase 替換了支付寶支付系統中的 Oracle 資料庫。2016 年，OceanBase 替換了支付寶最核心的賬務系統中的 Oracle 資料庫。2017 年，螞蟻金服全面去 IOE。

從 2011 年開始參戰雙十一到 2016 年雙十一支付寶支付峰值 12 萬筆/秒的世界紀錄，再到 2017 年雙十一支付峰值達到 25.6 萬筆/秒，再次刷新 2016 年創下的峰值紀錄，這背後，是一個由 OceanBase 研發和運維組成的幾十人的團隊。2016 年的世界互聯網大會，OceanBase 入選世界互聯網領先科技成果，其它獲獎公司還包括特斯拉、IBM、微軟、卡巴斯基等。

在 6000 多名螞蟻員工中，這幾十個人辨識度很高，因為只有他們的工牌帶是「土豪金」，而其他所有人的工牌帶都是清一色螞蟻藍。「土豪金」工牌帶是螞蟻金服內部最高榮譽——CEO 大獎。2016 年 5 月，螞蟻金服董事長彭蕾親自為這幾十位技術明星戴上了「土豪金」 工牌帶，理由是這個小團隊自主研發的 OceanBase 資料庫，以遠低於傳統資料庫的成本，更高的可用性，扛住了支付寶一次又一次自我刷新的支付峰值世界紀錄，打破了 IT 核心技術長期被西方壟斷的格局。

從 2017 年開始，OceanBase 跟隨整個螞蟻金服的金融科技開放，開始了向傳統金融賦能的實踐過程。2017 年年底，OceanBase 在南京銀行正式上線，OceanBase 資料庫為南京銀行「鑫雲+」互金開放平台提供金融級分散式關係資料庫服務。OceanBase 還出口到了印度和美國等地，為當地的支付業務提供資料庫服務。作為螞蟻金服自研的分散式關係型資料庫，OceanBase 從一開始的目標就是傳統商業資料庫的升級換代產品，並堅持走通用關係資料庫產品之路。

經歷了 7 年坎坷、成立的頭三年一直被邊緣化、多次面臨解散的 OceanBase 團隊，如今雖然集體戴上了「土豪金」，可是他們都知道 OceanBase 這樣的中國技術奇蹟，是阿里巴巴/螞蟻金服舉全集團之力所創造出來的成果，這個過程本身也堪稱「奇蹟」。2018 年 2 月初，OceanBase 團隊的主幹成員陽振坤、馮柯、陳萌萌、蔣志勇、楊傳輝等與筆者展開了深入的交流，介紹了 OceanBase 的來龍去脈。

▌OceanBase：劃時代的資料庫

OceanBase 團隊 SQL 開發方向負責人 陳萌萌

為什麼 OceanBase 能夠入選世界互聯網領先科技成果，能夠進入 IBM、微軟等世界科技巨頭行列？首先，簡要回顧一下基礎軟體歷史。自 1975 年微軟公司創立、1977 年甲骨文公司創立後，逐漸出現了商用操作系統和商用關係型資料庫產品。再加上 1995 年創立的 BEA 公司及其代表的商用中間件產品，傳統基礎軟體的核心技術：操作系統、中間件和資料庫，就此誕生。

除了 BEA 公司於 2008 年被甲骨文公司收購外，為什麼後來全球再也沒有企業能夠超越微軟和甲骨文公司的操作系統與資料庫及中間件產品呢？這其中的原因很多，除了最早投入、培養了最多的相關技術研發人才和技術積累外，更重要的原因在於作為全球化的商用軟體產品，無論是微軟的操作系統還是甲骨文的資料庫，都是伴隨著全球用戶集體使用、集體反饋、集體推動技術進步而打磨出來的。

實際上，無論是操作系統、資料庫還是中間件，本質上都是軟體和硬體集成在一起的優化技術，其目的就是通過軟硬體集成調優來達到計算效率最大化、成本最優、用戶體驗最佳、兼容性最廣、安全與穩定性最高等結果。以甲骨文公司的 Oracle 資料庫為例，其廣泛支持並行機、大型主機、小型計算機、工作站、個人電腦等多種計算設備，允許用戶在不同計算設備上使用並遷移 Oracle 資料庫，1994 年的時候 Oracle 關係型資料庫支持超過 100 種硬體和操作系統環境，兼容多項國際及國家的資料庫相關標準。

令 Oracle 資料庫成名的，是 OLTP 聯機交易處理也稱為面向交易的處理過程，其基本特徵是前台接收的用戶數據，可以立即傳送到計算中心進行處理並在很短的時間內給出處理結果，針對諸如銀行、證券、民航訂票系統等需要實時響應的關鍵性業務系統等。Oracle 資料庫在全球的金融、電信、民航等各類系統和業務場景中得到了廣泛的應用，在應用過程中不斷改進技術，最終出現了一個「強者恆強」的結果。

正因為 Oracle 資料庫在關鍵性的 OLTP 交易處理中佔據了牢不可破的市場地位，這讓後來的資料庫廠商很難有機會再重複一遍 Oracle 資料庫曾經走過的這樣一個反覆實踐、反覆打磨、反覆修正的過程。原因很簡單，不會有企業願意把自己的核心業務拿出來，給新進技術廠商當實驗田。所以在以 IOE 為代表的傳統 IT 環境中，除了已經建立起市場地位的主流技術廠商外，其它的後起技術廠商包括開源技術開發商，只能在企業的邊緣業務或當地政府扶持的業務場景下，才有少量的機會。

這種情況一直持續到近十年的雲計算變革。雲計算實際上是由大型互聯網公司發起和主導的技術變革，在最近幾年逐漸從互聯網公司向傳統企業蔓延。雲計算的初衷是大型互聯網公司為了降低自己的 IT 支出，而從 IOE 架構向基於廉價 PC 伺服器為主的 IT 架構進行演變的過程。雲計算最早起源於 2006 年亞馬遜推出的 Amazon Web Service 網路服務，簡稱 AWS。而到了 2008 年王堅成為阿里的首席架構師，負責集團每年的 IT 規劃與預算，這個時候王堅就意識到了 IOE 架構對於阿里長期運營成本的影響以及對未來業務發展的制約。

在 2008 年的時候，阿里的資料庫就已經是全亞洲最大的資料庫，也是 Oracle 最大的用戶之一，那年阿里還沒有啟動雙十一。從 2009 年開始的雙十一，每年產生和處理的數據量都在爆髮式增長，如果一直採用 Oracle 資料庫的話，運營成本將是天價。而在另一方面，為傳統 IT 環境而設計的 Oracle 資料庫，並沒有考慮到互聯網的大規模、高並發、實時在線、大型網路優化等新興需求。2008 年的時候，Oracle 資料庫就已經難以處理阿里的大規模數據量了。

本質上理解，OceanBase 與 Oracle 資料庫一樣都是關係型資料庫，但不同的是 OceanBase 是面向超大規模互聯網公司的分散式計算環境而重新開發的關係型資料庫，Oracle 資料庫則相應可以理解為針對傳統企業的計算環境而形成的「單機」資料庫。

所謂「單機」資料庫，首先指 Oracle 資料庫所基於的硬體環境是 IBM 小型機和 EMC 企業級存儲所構成的高度穩定共享存儲環境，IBM 與 EMC 的企業級硬體本質上就提供了高度穩定的共享硬體環境。其次，Oracle 資料庫以共享存儲為理念，所有的資料庫看到的是同一個數據磁碟、共享數據訪問，因而可以確保所有的數據都可被訪問到，而且底層硬體本身也穩定可靠，所以是「單機」視角。

陳萌萌目前在螞蟻金服基礎數據部（OceanBase 團隊）負責 SQL 相關方向的開發工作。2006 年畢業於清華大學、2006 年到 2008 年在歐洲核子研究中心（CERN）負責網格計算調度器的開發工作、2009 年 5 月在美國威斯康辛大學麥迪遜分校獲得計算機碩士學位，陳萌萌先後在 Oracle、華為美國研究所從事資料庫的開發和研究，他於 2014 年 6 月加入 OceanBase 團隊。

陳萌萌對於「單機」的視角有一個形象的比喻：就像今天使用 PC 伺服器，要擔心如果突然某台 PC 伺服器掛掉了、甚至機房本身遭遇地震、火災等極端情況，如何保障數據訪問的穩定性。由於是完全基於 PC 伺服器架構，OceanBase 在處理數據訪問的時候，相當於把一台原來的小型機或存儲設備從縱向「切片」成很多機器，再把數據分布到這些分散在不同的機器上，數據需要通過網路才能夠被訪問到。「以前是一個磁碟，現在看到的是幾十個甚至幾百個分布在不同地方的磁碟，怎麼做查詢優化？這個訪問模式會非常不一樣。」

過去的傳統 IT 環境是集中在一個地點的高穩定、高可靠、高可用高端企業級設備，現在的雲計算環境是分散在不同地點甚至跨國家區域地理位置的廉價 PC 伺服器機群。OceanBase 與 Oracle 資料庫是基於同樣的資料庫原理，但底層的基礎計算環境發生了根本性的變化，這對於像亞馬遜、阿里巴巴/螞蟻金服和谷歌這樣的互聯網公司來說，有三條出路：一是與甲骨文公司合作，全面開放自己的業務和數據；二是採用 MySQL 等開源資料庫技術進行改良；三是從頭開始重新設計一個完全自主知識產權的資料庫產品。顯然，亞馬遜、阿里巴巴/螞蟻金服、谷歌都不約而同地走上了自研的道路。

這個原因其實很簡單，如果與甲骨文公司合作，需要全面開放自己的業務和數據不說，更重要的是互聯網公司的快節奏、快響應、快研發、與業務運維並肩開發等特點，已經超越了甲骨文公司等上一代 IT 公司的企業文化和公司機制。而對於開源技術來說，不同的開源資料庫只適用於特定的業務場景，由不同的開源社區「各自為戰」式主導各自的技術方向，互聯網公司需要針對不同的業務場景拼接不同的開源資料庫到一個大系統中，這無疑也不利於長期發展。而走全面自研的方向，是一種最辛苦、看似最不可能卻最具長期投資價值的選擇。

馬雲曾經針對阿里自研雲計算等新一代 IT 技術說：「網上很多人批評說我被王堅忽悠了，這個雲計算要把 5000 台計算機合在一起，是根本不可能實現的……騰訊、百度沒搞下去，重要的原因是他們的領導知道這個搞不下去。」相反，不懂技術的馬雲，卻最堅定地支持自研雲計算等新技術。「想也沒想，從預算、人頭、資金，我們一路投，最後我們走了出來。」

王堅從 2009 年開始在阿里搞雲計算，陽振坤從 2010 年加入阿里後開始搞 OceanBase，兩條線幾乎是同時並進。陽振坤回憶，整個 OceanBase 其實並沒有一個產品經理，根本的原因是 OceanBase 作為商用關係型資料庫的升級換代產品，在 OceanBase 立項伊始就參照商用關係資料庫列了一個長達千頁的產品功能列表，隨後的 OceanBase 開發過程就是根據這個列表，但卻從分散式計算的角度重新實現每一個功能。「直到 2018 年初，OceanBase 還只是實現了這個列表中的部分核心功能，但足以支撐整個螞蟻金服的業務」，陽振坤表示。從 2017 年開始，三年之內，OceanBase 要實現商用關係資料庫的絕大部分功能。

能夠與 OceanBase 類比、可以稱為分散式資料庫的產品，目前只有谷歌於 2017 年 2 月發布的 Spanner 資料庫雲服務。陳萌萌認為，Spanner 是谷歌從頭開始全部自研的分散式資料庫，也是針對谷歌的交易業務場景，但總體來說並沒有阿里巴巴及螞蟻金服的交易業務規模大，而 AWS 推出的 Aurora 資料庫則更接近於 Oracle 資料庫的共享磁碟設計。「真正用分散式架構解決像螞蟻金服這麼大規模事務性需求的分散式資料庫，目前我們只看到 OceanBase 這一家」， 陳萌萌表示。

從第一行代碼起步到今天的百萬行代碼級產品、支撐雙十一的十萬筆級每秒支付峰值以及螞蟻金服的全面業務，OceanBase 可以說創造了一個劃時代的資料庫產品。OceanBase 是中國第一個具有自主知識產權的分散式關係資料庫，也是全球首個應用在金融核心業務的分散式關係資料庫。業內人士認為，OceanBase 的出現，在高端金融領域打破了傳統商業資料庫的壟斷，為金融科技的國產化進程邁出了重要一步。

▌OceanBase：劃時代的中國技術

OceanBase 團隊架構師 馮柯

現任螞蟻金服基礎數據部（OceanBase 團隊）架構師的馮柯，於 2014 年加入螞蟻金服，目前的技術領域為分散式關係資料庫、數據存儲、性能診斷和優化。馮柯在入職螞蟻金服前，曾在國內資料庫廠商天津神舟通用數據技術有限公司（以下簡稱：神舟通用）任 CTO，是浙江大學計算機應用專業博士，具有 15 年的資料庫研發和產業化經驗。

作為國內最早一批從事國產資料庫開發者之一，馮柯表示國內早期從事國產資料庫開發的人們，基本都成為先驅了。以前做國產資料庫，更多體現的是國家科研的意志，而不是企業的市場化行為。更為重要的是，自主研發資料庫需要的是行業背景和企業實踐。「資料庫產品是用出來的，不只是被研製出來的。」馮柯強調。專註於國產資料庫的國內的資料庫專業公司，到後來往往發展的不好，就是因為沒有行業屬性、沒有真正能夠找到成熟應用的市場。

「我當時加入螞蟻金服的時候，覺得螞蟻金服自主研發 OceanBase 這件事其實很另類，覺得非常不可思議。而且阿里巴巴原來是開源文化，為什麼會完全從頭開始做一個資料庫，這直到今天還是一個非常奇妙和神奇的事情。」馮柯回憶說，很多人都會問為什麼不從 MySQL 開源資料庫入手，「不管是自主研發，還是基於開源產品來做，從技術上面來看，沒有絕對的對和錯，很多時候是理想主義使然。」

正如馬雲所說，阿里巴巴/螞蟻金服對於雲計算和通用資料庫等自研技術的投入，正是理想主義的結果。在 2017 年 9 月的阿里巴巴 18 周年年會上，馬雲說：「讓阿里巴巴堅持 18 年的是因為我們有理想主義，堅持理想主義使阿里巴巴走到了今天。」「絕大部分人是因為看見而相信，很少部分人是因為相信而看見，」這是馬雲在阿里巴巴 18 周年年會上引用的話，「過去的 18 年，阿里是因為相信才有今天。」

蔣志勇現在是螞蟻金服基礎數據部（OceanBase 團隊）SQL 組負責人，致力於高可用、高性能、高可擴展性併兼具成本優勢的分散式關係資料庫系統。蔣志勇於 2014 年加入螞蟻金服，之前在神舟通用負責資料庫開發長達十年之久。蔣志勇在浙江大學完成了計算機專業的本科和研究生學業後，即加入了中國航天科技集團下面的一家研究所，從事國產自研資料庫開發，當時主要為了科研服務的資料庫及存儲系統。蔣志勇在研究生期間就已經參與到該科研項目中，後來就加入了航天科技集團組建的專註於國產資料庫開發的神舟通用公司。

作為國內早期從事國產資料庫開發工作的專業人員，蔣志勇認為螞蟻金服開發自研資料庫與其它專業資料庫公司開發自研資料庫的最大區別在於螞蟻金服自有業務場景。「螞蟻金服不是一家資料庫公司，而是一家金融科技公司。OceanBase 在螞蟻金服內部發展的一個基本前提，是能夠為業務不斷創造價值，這是跟傳統資料庫公司的最大差別。」

「之前的困境是開發了很多技術，但是很難找到一個真實的大規模場景去使用這些技術。但在螞蟻金服這邊就不一樣，我們做的技術都是業務部門迫切需要的、確實能解決業務痛點問題的技術，加上螞蟻金服的業務發展非常快，也逼著技術部門把產品做的更好，這是一個正向循環：不斷促進技術開發，同時又能對開發成果提供真實業務場景下的及時反饋。」 蔣志勇介紹說。

作為整個 OceanBase 的始作俑者，陽振坤的感受最深。「做自研資料庫，這真的是一把手工程，只有真的獲得企業最高層的決策支持才能做成。對於業務部門來說，哪個資料庫最穩定、最好用，就會選用哪個資料庫，因為業務部門的首要目標是發展業務。」為了嘗試自研資料庫技術，螞蟻金服的業務部門需要付出的代價是：修改業務系統，同時支持兩種資料庫，兩邊要能夠隨時切換，以便保證在自研資料庫出問題的情況下，還能夠切換回原有的 Oracle 資料庫。「所以一開始業務團隊在這件事情上其實並沒有積極的理由。」

為什麼說 OceanBase 是阿里巴巴/螞蟻金服舉全集團之力所創造的成果呢？陽振坤一直是從事分散式技術的專家，2006 年他從微軟到百度，從事分散式系統研發。對於百度數以萬億計的網頁來說，意味著與日俱增的天量數據，雲計算系統有非常好的發展機會。陽振坤在百度做了兩年多的自研分散式系統，但由於百度不願意再投入更多資源而最終採用了一套現成的開源系統，陽振坤的團隊也被解散了。

來到阿里之後，陽振坤與其它阿里技術人員一樣，需要找到一個合適的業務場景，跟一個業務團隊並負責技術，為自己的技術方向謀一條「生路」，同時隨著業務的發展而壯大自己的技術。淘寶的技術「大牛」，大都是通過這條路徑成長起來的。在加入淘寶之前，陽振坤其實並不懂資料庫，他的本科與碩士都是數學專業，到了博士才轉到了計算機專業，因此陽振坤的長項在於基礎計算科學。

當陽振坤加入淘寶後，最開始選擇自己技術方向的時候，恰好趕上了一個千載難逢的「天時」與「地利」。「天時」就是當時互聯網對資料庫的需求激增。以前金融企業等用的 Oracle 資料庫，都是事先設計好業務場景，比如固定用於銀行櫃檯和 ATM 機器、服務於固定的人群，資料庫的並發量也很小，原來資料庫有幾十到幾百個人、最多幾千人的並發量就不得了，到了阿里巴巴雙十一以及支付寶業務的時候，一下就激增到幾十萬、上百萬人甚至是上千萬人的並發訪問，結果就是要原來的 IOE 投資要放大幾百倍甚至幾千倍，「誰都買不起了」。

而「地利」就是阿里巴巴/螞蟻金服自有龐大的業務和資料庫。「當時來阿里的時候，『單機』在阿里系統內部就已經走到盡頭了。IOE 等『單機』的性能再好，也有個盡頭；『單機』的盡頭，就是分散式系統的開始。」 陽振坤及其團隊恰好是做分散式系統出身的，而阿里巴巴/螞蟻金服內部有數以萬計的資料庫。雖然資料庫作為 IT 系統的底層，一旦出現故障就會嚴重影響整個業務系統，特別是支付等關鍵業務系統。但阿里內部總有一些業務，因為數據量和自身業務需求等因素，可以先試用自研技術，從而打磨自研技術。

淘寶收藏夾就是這樣一個業務，有大規模的數據量，其業務需求傳統資料庫又難以滿足。2011 年的時候，淘寶用戶已達數千萬級，就算每人收藏十條即達幾億條的數量級。另外，淘寶收藏夾業務還有一個特點，就是資料庫訪問邏輯不太複雜，可以讓 OceanBase 團隊在短時間內開發出代碼並投產使用。如果選擇非常複雜業務作為目標，那麼可能需要耗費技術團隊幾年的時間才能開發出一個可用的版本，而業務卻不可能等這麼長的時間。

這個項目取名 OceanBase，相對於 Database 而言，寓意要做一個海洋一樣的海量資料庫系統。完成了淘寶收藏夾的挑戰後，很快就難以在淘寶內部找到類似的業務場景，可以讓 OceanBase 技術團隊繼續生存下去。淘寶的核心業務已經應用了 MySQL 開源資料庫並且比較穩定，MySQL 已經能滿足淘寶的大部分業務需求。到了 2012 年的時候，OceanBase 團隊面臨要解散的危機。這個時候，王堅聯繫了當時的螞蟻金服 CEO 彭蕾，把 OceanBase 團隊推薦到了支付寶。而螞蟻金服的 CTO 程立，又極大地支持了 OceanBase 的發展。2014 年雙十一，程立出面，把交易流量的 1%切給 OceanBase，但實際的結果卻是切了 10%，因為當時的 Oracle 資料庫系統確實支撐不了洶湧而來的巨大流量。

後來的結果是 OceanBase 成功支撐了 2014 年雙十一 10%的交易流量。但就在 2014 年 6 月份，當 OceanBase 已經從技術上準備好，需要切到交易業務時，因為業務系統改造的工作量大，導致 OceanBase 兩個月都無法上線。「到了 8 月份，我急了，就給魯肅（程立）和 Lucy（彭蕾）寫郵件，這個事情後來就推動了。」

除了王堅、彭蕾、程立等阿里巴巴/螞蟻金服等「一把手」對於 OceanBase 的大力支持外，當時負責阿里巴巴整個後台系統的劉振飛從第一天起就一直是 OceanBase 的堅定支持者。劉振飛於 2006 年加入阿里，曾任淘寶技術保障部總監，後來升至阿里巴巴副總裁負責技術保障部、是阿里巴巴合伙人之一，現任阿里集團首席風險官兼任高德總裁。正是劉振飛的支持，才讓淘寶收藏夾用上了 OceanBase。「當時振飛負責整個阿里巴巴的後台系統，包括資料庫，沒有他的鼎力支持，OceanBase 無法在任何業務上線。」陽振坤回憶。

「甲骨文公司有十幾萬人，從事資料庫核心研發的就有 2 千多人，而 OceanBase 一開始只有幾個人，到後來也才 20 多個人，憑什麼讓別人相信我們能做出比 Oracle 資料庫更好的技術與產品？這個確實聽起來就不靠譜。」陽振坤說，這就是雞生蛋、蛋生雞的問題，好的產品必須要有好的口碑才會有人用，但好的口碑和好的產品卻要在使用中才能打磨出來。資料庫是做出來、更是用出來的，中國有那麼多企業、高校和科研機構做資料庫，真正能夠在生產環境中大批量使用的少之又少。

今天回頭來看，OceanBase 是阿里巴巴/螞蟻金服舉全集團之力而開發出來的自有知識產權資料庫，如果沒有阿里巴巴/螞蟻金服內部眾多「一把手」高管的鼎力支持，OceanBase 團隊也許早就解散了。

▌技術成就：劃時代的分散式資料庫

OceanBase 團隊複製資料庫事務開發的研究員 楊傳輝

通過核心業務的不斷上線，螞蟻金服幫助 OceanBase 渡過了自研基礎軟體產品最艱難的應用關。OceanBase 不只是被研發出來的，更是被用出來的，是在生產系統中被磨練出來的。螞蟻金服作為互聯網金融的標杆企業，也通過 OceanBase 的應用，於 2017 年真正實現了所有核心業務 100%去商業資料庫，這對整個金融體系來說都是具有里程碑意義的事件。

今天的 OceanBase 已經支持了阿里巴巴/螞蟻金服數百個關鍵業務的執行，其中有很多業務已經穩定的運行了多年。2017 年天貓雙十一，支付寶創造了 25.6 萬筆每秒支付峰值的業界新紀錄，這對於資料庫來說，意味著每秒需要同時運行 4200 萬條 SQL。

市場對關係型資料庫的性能和穩定性要求苛刻，真正的關係型資料庫都是磨礪出來的——OceanBase 用了 7 年多的時間才取代 Oracle 成為了支付寶的賬務等資料庫。從 2010 年 5 月調研、6 月 25 日立項開始，OceanBase 的目標就是成為新一代的商用關係型資料庫產品，差異化競爭點在於底層的分散式技術。全球三大資料庫廠商已存在幾十年，每家公司都擁有數以萬計的員工，而 OceanBase 之外做分散式資料庫的全球唯一一個成功案例是谷歌。

OceanBase 等後來者反映了以互聯網為代表的新興社會生產力對關係資料庫的新需求：互聯網訪問的用戶數量無法確定，可能在幾天甚至幾小時內增長數倍，傳統資料庫的垂直擴展方式根本無法應對。而全球前三大資料庫甲骨文、IBM、微軟都採用集中式系統的重要原因在於主機系統的穩定性，一台主機動輒數百萬美元，存儲空間不夠就只能再買一台，而且新主機系統上線還要數天時間。

楊傳輝現任螞蟻金服基礎數據部（OceanBase 團隊）研究員，目前負責資料庫事務開發工作，著有《大規模分散式存儲系統：原理解析與架構實戰》一書，他從武漢大學畢業後加入百度從事大規模分散式存儲系統開發，後隨著陽振坤轉戰阿里系從事 OceanBase 系統開發，是 OceanBase 0.5 和 1.0 版本的總體設計師。

楊傳輝總結 OceanBase 的六大特點：第一高可用、第二強一致、第三易用性、第四高性能、第五可擴展、第六低成本。

OceanBase 作為分散式關係型資料庫，最大的特色在於分散式架構，而分散式架構的一個基本特徵是能夠基於普通的 PC 伺服器，構建一個滿足金融級更高的可靠性以及數據一致性要求的業務核心。而 PC 伺服器硬體的不可靠，可以通過架構設計和軟體的可靠性來彌補，螞蟻金服的多年實踐已經非常清楚地向業界證明了這一點。

OceanBase 又被稱為原生的分散式關係型資料庫，即 OceanBase 是真正把所有與高可用及數據一致性相關的問題在資料庫內核層面就解決掉了，這和現在很多互聯網公司採用的中間層+單機資料庫的分層設計方式有很大的差別。從技術複雜度上看，選擇走原生分散式資料庫這條路，無疑是非常艱難和痛苦的，這意味著在這樣的一個複雜的分散式內核上，哪怕是實現一個簡單的功能，也需要付出比單機資料庫大得多的代價，但正是這樣的選擇，使得 OceanBase 真正具備了商業資料庫最重要的特徵：高度集成、整體交付，對業務無侵入；同時也真正解決了分層設計中無法同時實現的水平擴展及跨庫查詢等缺陷。

OceanBase 的一個基礎設計思想是把每一份數據存放在三台不同的機器上，那麼一台 PC 伺服器出故障的概率為千分之一的話，兩台同時壞的概率可能就是百萬分之一，三台同時壞的概率則是十億分之一。這樣做的成本雖然下來了，但如何保證三台機器上數據的強一致性，這對於金融業務來說至關重要。

OceanBase 高可靠的核心是基於 PAXOS 協議。PAXOS 協議原來為分散式理論上的演算法，OceanBase 在分散式資料庫中實現了這一協議。PAXOS 協議本質是少數服從多數的協議，具體實現：在 n 個(n>=3)個資料庫中，其中一個為主庫，其餘為備庫，每一筆事務不是同步到所有備庫，而是同步到超過半數的庫（包括主庫自身），比如 3 個庫中的 2 個、5 個庫中的 3 個等等。一旦主庫故障，只要存活的庫超過半數，就可以自動選舉出新的主庫，並且恢復所有已經提交的事務（超過半數庫或者保證了每一筆提交的事務至少在一個庫上存在），這樣就允許少數的庫故障而不丟失數據、不中斷業務。基於 PAXOS 協議，OceanBase 能夠實現單機/機房/城市級別，真正的無損容災；在少數庫故障的時候，RPO（恢複目標）為零，即沒有數據因為故障而損壞或丟失；同時基於完全自動的主備切換，能把 RTO（恢復時間）縮短到 30 秒以內。

在強一致性方面，OceanBase 還做了大量優化工作。比如對於事務消息改造為非同步消息機制：事務開始時把消息投入消息系統，當交易全部完成後才通知消息系統投遞消息，而這個是一個非常關鍵性的改造，解決了高並發支撐同時的一致性問題。

所謂事務（transaction），這是面向 OLTP 交易型關係資料庫的一個關鍵流程。對於交易來說，資料庫的事務必須是「原子」的，典型的是銀行轉賬：這邊扣了 100 塊錢，另一邊就必須加上 100 塊錢，而不能這邊扣了那邊卻沒有加上。

為了保證資料庫的高可用，OceanBase 實現了三地五中心容災架構在核心業務的落地，即使一個城市的所有數據中心都完全不可用，整個系統在數據層面仍然會做到不丟一行數據並繼續提供服務。例如支付寶的會員 ID 採用了 OceanBase 的三地五中心部署方案，即使其中一個城市故障，剩下的兩個城市至少還有 3 個活著的庫，仍然能夠自動選舉出新的主庫、立即恢複數據，並繼續提供服務。

在易用性方面，OceanBase 作為後來者，必須要考慮到已有資料庫用戶的習慣，必須要兼容已經有的技術與產品，特別是在做資料庫遷移的時候，最好是原有的軟體代碼不需要改動一行也能直接遷移到 OceanBase 上，這就是易用性。

在可擴展性方面，每一個城市裡面的機房可以想像為一個可分片的大型資料庫，可作為數據拆分的基礎，例如把全中國的所有用戶分成一百份，那麼一份放在第一個機房，依此類推使得整體伸縮能力可達到機房級。理論上只要增加機房，就能無限增加伸縮能力。不論跨越多少個機房、多少個城市，所有參與部署的資料庫伺服器在邏輯上是一個 OceanBase 集群的一部分，這就是所謂「原生」的概念，無論從應用視角還是運維視角，都是整體交付。

通過原生的分散式資料庫設計，OceanBase 實現了高可用、強一致、易用性、高性能和可擴展，這樣帶來的好處就是 OceanBase 性價比能做到傳統資料庫的 10 倍甚至更高，原先一台高端伺服器動輒幾十萬、幾百萬，而 OceanBase 僅用幾千元至多幾萬元的 PC 伺服器即可，這從根本上來說就不是一個量級，諸如大型銀行使用的大型機可能以幾千萬、幾億元來計算。陽振坤表示，OceanBase 的性價比已經達到了現有商業資料庫的 5 倍~6 倍以上，未來還將達到更高。

OceanBase 的開發分為兩條線：一條線是從 2010 年開始開發的 0.1、0.2、0.3、0.4、0.5 這一系列的版本，主要是早期為了服務當時已有的阿里系業務；另一條線是從 2012 年開始構想的、完全從雲時代架構重新設計的分散式資料庫 OceanBase 1.0 系列，2013 年開始整體設計、2014 年中旬抽出資源正式投入開發、2015 年底開發完成，後又經歷了 1.0、1.1、1.2、1.3 到現在的 1.4 版本。

2016 年雙十一的時候，有些支付寶業務還是基於 0.5 版本，有些業務已經升級到 1.1 版本，少量業務升級到 1.2 版本。而 2014 年雙十一，10%的交易數據鏈搬到了 OceanBase 上；2015 年雙十一，100%交易數據鏈和支付數據鏈都搬過來了；2016 年雙十一，整個賬務庫都搬過來了，這一核心資料庫被稱為「金融系統資料庫皇冠上的明珠」。

▌研發故事：軟體、硬體、業務一體優化

OceanBase 團隊 SQL 組負責人 蔣志勇

對於 OceanBase 這樣一個劃時代的分散式資料庫，自然有寫也寫不完的研發故事，以下僅摘取幾例以體現 OceanBase 的研發之難。

陳萌萌介紹說，以前資料庫技術更多偏向軟體層的，硬體層有專業人員、專業技術和專業的公司來解決硬體本身的穩定性或容災等問題。但是在螞蟻金服這邊更多是軟硬結合的方案，OceanBase 軟體從設計之初就考慮了硬體層面不穩定、分散式系統的特徵，從而去做以前資料庫不會做的優化工作。以前的資料庫優化根本不會考慮到底層的硬體損壞、機器宕掉、網路斷網、天災人禍不確定性問題，而今天 OceanBase 無時無刻不在考慮這些問題。「以前做軟體開發，先假設底層的硬體沒有問題，而只需要把上層軟體邏輯做好就行了，現在我們是整體的軟硬體考慮。」

以資料庫的查詢優化技術來講，比如傳統的銀行櫃檯，通過人工窗口提供服務，用戶的主要時間花在與人工窗口打交道等方面，對於資料庫的快慢體會不那麼敏感，但是螞蟻金服是互聯網應用，資料庫隨時的一個抖動或查詢執行時間變慢了一點，用戶馬上就能直接感受到。這與傳統應用場景差異很大，如果資料庫的一個查詢從一毫秒變到了五毫秒，傳統資料庫不會認為這是件大事，但是互聯網應用下，多出來的四毫秒可能被放大成為幾百毫秒甚至一兩秒，一旦出現這樣的時延，用戶體驗馬上就變差了。「我們每天都在做特別精細的事情，生怕一毫秒變成五毫秒這種事情出現，因此做了很多精確防禦。」

楊傳輝進一步解釋。資料庫查詢優化器本身是近似解，基本上不存在最優解，優化的目標就是逼近最理想的情況。在傳統應用場景下可以允許優化結果差幾個毫秒甚至更多，但是在互聯網場景下就很難接受這麼大的差異，所有的優化效果都要精確到幾個毫秒以內。

比如每一次在支付寶付款，點擊一下支付寶的付款按鈕，背後的資料庫可能要執行一兩百次資料庫的 SQL 查詢，優化器要為每一個查詢生成一個需要做的優化執行計劃，如果優化器在某一個場景下犯了一個錯誤，每個查詢多出了 5 毫秒，那麼整個鏈路就會多 500 毫秒，用戶在按下付款按鈕的時候發現有可能變慢了。如果再加上可能不止做支付，比如買商品後下單再要支付，這幾個鏈路加在一起就有可能慢幾百毫秒甚至上到秒級，這對用戶來說就已經不能接受了。

還有一個場景是地鐵的刷臉或者刷支付寶進站，如果用戶站在閘機前面半天刷不出來，那就不光是體驗問題了，有可能會引來連鎖麻煩，後面人也會被堵起長龍，這些現實的挑戰都要求 OceanBase 反應精確、迅速。楊傳輝介紹說，從關鍵業務系統的數據鏈路梳理上來看，一兩百條 SQL 是最普通的一次交易了，如果涉及到支付渠道不一樣，SQL 執行的次數就會更多。

因為螞蟻金服本身是分散式的系統，分散式系統一個很大挑戰是對底層的基礎組件包括網路要求非常高。如果網路出現了問題，就會對整個服務產生影響。因此 OceanBase 不僅要對資料庫層做優化，還對網路、磁碟、操作系統等軟硬體層都要做很精確的優化。

那麼 OceanBase 是怎麼解決的呢？OceanBase 團隊從業務的開始階段就會介入到業務的設計當中，業務怎麼用資料庫、怎麼用最合理等等，從一開始就會參與整體設計，與業務方和整個架構一起演進。

蔣志勇所從事的 SQL 引擎和優化器工作，為 OceanBase 從無到有的建立了自己的 SQL 引擎，特別是讓原先的 MySQL 應用不改動任何代碼就能遷移過來。在資料庫的兼容性方面，OceanBase 做到了對 MySQL 的兼容，螞蟻金服的內部業務從 MySQL 資料庫遷到 OceanBase，不需要任何改動。

在優化器方面，涉及到的系統統計信息收集，是與螞蟻金服的業務體系架構結合起來，設計了一個動靜分離的架構：白天把統計信息都存儲到內存中，每天到業務低谷的時候再從內存寫到磁碟上。而不是像其他資料庫那樣直接寫到磁碟上，導致收集系統統計信息慢且不全面；也不像內存資料庫那樣全採用高成本的內存來存儲統計信息。OceanBase 的這種准內存資料庫設計方式，既滿足了 SQL 查詢需要實時收集更全面系統統計信息的需求，也讓整體的信息收集成本沒有額外開銷。

OceanBase 還在 SQL 語句搜索優化方面進行了精細化的調節。由於是完全自研的資料庫，對於 Join 連接查詢演算法可以靈活適配多種演算法，而在其他資料庫中則由於已經限制可選範圍而無法做到更精細的優化。「我們在搜索條件的改寫上面做了巧妙的設計，結果就是有更廣的可選擇範圍，而其他資料庫則只能在一個很窄的範圍內選擇最優策略，因此 OceanBase 的搜索結果更優。」蔣志勇說。

因為要兼容 MySQL，OceanBase 團隊也精研了 MySQL，對 MySQL 進行了大量調優工作。在這個過程中，OceanBase 團隊發現了 MySQL 的幾百個問題，向 MySQL 開源社區彙報後得到了確認。諸如 MySQL 對不同路徑執行出來的結果都不一樣、MySQL 的語義不是非常完整等等，都是 OceanBase 團隊在使用 MySQL 中發現的問題。特別是由於阿里巴巴和螞蟻金服的業務規模日益擴大，經常會踩到各種技術的極限門檻，OceanBase 團隊就曾經在開發 MySQL 介面驅動程序的時候，通過業務排查發現某個事務已經回滾但數據還是被提交進入了資料庫，導致會出現轉賬已經取消但錢還是被轉走了的現象，團隊排查了很久後終於發現是由於 MySQL 客戶端的一個變數設置本身有問題，但這種問題只有在極限條件下才有可能出現，屬於小概率事件。OceanBase 團隊就是這樣逐一排除小概率事件，最終走向了通用型產品的道路。

通用型產品與場景化產品最大的區別在於通用型產品能夠適配絕大多數場景，而場景化產品則只能適配單一的場景。馮柯表示，這就是商業資料庫最強的地方，因為能夠匹配絕大多數的場景。也許商業資料庫的技術不是最強的，但價格那麼貴還有用戶買，就說明商業資料庫的總體擁有成本更低，一個產品就能適配大多數場景。而能夠適配絕大多數場景，就說明把已經能踩的坑兒都全部踩過了，今天的 OceanBase 也在經歷同樣的過程。

OceanBase 踩過的另一個坑兒，也是在極限情況下才會出現的 Linux 系統 bug。OceanBase 本身是在 Linux 和 C 語言基礎上開發的分散式資料庫系統，2010 年到 2011 年 OceanBase 團隊在支持淘寶收藏夾業務，2011 年雙十一的時候遇到了穩定性的問題。當時的 Linux 有一個直接訪問 IO 的特性，這個特性出現了 bug，而且是在極限條件下才會被觸發的 bug。

楊傳輝回憶當時距離 2014 年雙十一還有不到一個月的時間，是一個周五出現的問題，導致淘寶收藏夾一天之內連續宕機三次、每次一個小時左右，每次宕機後恢復收藏夾的流量，一旦訪問量超過一定量就又觸發了 Linux 內核的 bug 導致再次宕機，直到周五晚上 8、9 點後淘寶訪問用戶變少後才恢復了運轉。由於當時的開發團隊主要集中在北京，因此第二天的周六早上所有團隊成員搭第一班飛機從北京飛到杭州來解決問題。「當時的氣氛很緊張，如果這個問題解決不了，OceanBase 團隊當時就會解散。」楊傳輝回憶當時的情況，而且在解決問題的時候，負責寫代碼的程序員的壓力也很大，後面有兩三個在盯著到底怎麼寫代碼。「當時也並不確定這麼做就一定能解決問題，只是覺得有 70%-80%的概率能解決問題，後來還真解決了這個問題。」

「阿里巴巴/螞蟻金服的系統發展太快、一直在變，OceanBase 也一直在開發新功能，又要支持線上業務，而雙十一的爆發可能會是平常流量的十倍，而像 Linux 內核 bug 這樣的問題，如果只是平常流量的一兩倍，是根本不會觸發的，它只有在爆發十倍的時候才會出現。所以我們特別緊張，也沒有時間讓我們仔細去分析，慢吞吞地解決問題。當問題來的時候，所有人加班解決，就是這樣。」楊傳輝說。

馮柯回憶說，他加入 OceanBase 後的第一件事是做診斷監控，當時沒有人願意做這件事，因為最主要是要到系統中埋點，大家都認可這件事很重要，但是沒有人願意去做，因為它涉及到所有的模塊，是一件非常吃力不討好的事情。而自己當時選擇做的原因，是因為這對業務來說非常重要，是必須要做的事情，當時也碰到了很多的挫折，出了很多問題。例如 OceanBase 診斷監控功能剛上線的時候，有 N 個人去看監控，會得出各種不同的結論來，「大家覺得這個功能完全不能用，覺得做得很爛，所以當時參加的同學很沮喪，覺得沒有被承認」。馮柯當時鼓勵團隊，最困難的時候反而是團隊進步最快的時候，「別人對你的批評最多的時候，其實是你進步最快的時候，你的產品能夠獲得更多資源，能夠被更多的人認識到，這其實是非常好的，那個時候的觸動確實很大。」

OceanBase 是一個一邊在業務中「討生活」，一邊尋找機會發展壯大自己的過程。在「討生活」的過程中，OceanBase 也會不得已做出妥協。楊傳輝回憶 2010 年的 OceanBase 版本有一個比較大的缺陷，就是設計了單點寫入。當時，把所有寫入數據全放在一台機器上，這個版本可擴展能力比較差，本質上只能做垂直擴展而沒有辦法做水平擴展。另外，因為每個寫入都要經過那個節點，最後整個性能也相對更差，資料庫的功能也受限。這主要是 OceanBase 早期的版本，當時團隊的資料庫經驗沒有那麼豐富，也沒有時間做長期的開發，直到 2015 年重新設計開發的 1.0 版本才是真正面向雲時代的分散式資料庫。這個期間，OceanBase 團隊也從各個渠道引進資料庫人才，最終實現了資料庫的重構。

OceanBase 經歷的失敗還有很多。楊傳輝回憶，OceanBase 在 2012 年 11 月份轉到螞蟻金服到 2014 年實現了交易系統，這之間的 2013 年其實在從事淘寶的庫存項目而不是交易系統。當時，OceanBase 團隊看到庫存的資料庫問題也是一大挑戰，這就像賣火車票系統的挑戰本質上也是減庫存問題——如果有兩人同時並發減庫存，就會亂掉。當時，淘寶的 MySQL 團隊也在做這個事情，最終業務部門選擇了 MySQL 的方案，就是因為業務團隊當時覺得用 MySQL 更放心，「就這一個原因，也沒有其他的點，最後沒有選擇 OceanBase，我們相當於那一年白乾，整個團隊白乾。但因為這個鋪墊，我們下一個交易系統真的做成了。」

▌OceanBase 的研發方法論

OceanBase 創始人 陽振坤

總結 OceanBase 的開發過程，總會試圖尋找一些研發方法論，就像微軟的軟體開發「三駕馬車」那樣的方法論。但正如陳萌萌所總結的：「我們其實更多的時候是與運維、業務團隊等一起在定義問題。我們會看到一些問題，找到真正要解決的問題是什麼，然後幫助用戶定義這個問題。在定義問題時，有時候我們會開一個會，分析某問題是由資料庫團隊解決、還是由業務團隊解決，而在開會之前可能大家都不知道最後要達到什麼樣的效果。很多時候我們在做這些不確定的事情。」

OceanBase 本身是在做一個沒有先例可參考的分散式資料庫，純粹做分散式系統，全世界谷歌做得最好。陽振坤在百度時所帶領的分散式團隊已經是國內當時最強的分散式技術團隊，也從谷歌吸收了很多分散式技術的思想。但當後來試圖把分散式架構與關係型資料庫結合在一起的時候，就再也沒有先人的經驗，而只能靠團隊自己琢磨。雖然 OceanBase 到目前為止還沒有發表過論文、還是在做業務，但楊傳輝回憶 OceanBase 中有很多是別人沒有想過方法，可能要做一個新的方案要想好久，要思考半年到一年後面再決定去做。

在具體開發的執行過程中，測試是很重要的工作。分散式系統的異常處理很容易出錯，平常機器不出故障，到上線業務突然出一個故障時，可能就是一個大故障，而這種異常處理的測試比較難。OceanBase 有容災模擬框架，就是隨時把一台機器殺死，而這樣的容災測試隨時在運行。另外，對於並發處理的測試，即某個條件的達成可以突然觸發兩個線程的先後順序或一個變數的訪問順序出錯，OceanBase 也是隨時在模擬這樣的場景，讓這樣的小概率事件儘早出現。

在開發的過程上，OceanBase 通常是一個人寫出來的代碼，要另外一個人去讀和審查，通過的代碼才會提交。OceanBase 團隊還寫了很多自動測試用的框架，開發人員要自己做單元測試和一部分的功能測試，集成測試則由專門的人來完成，OceanBase 的測試人員很少只有幾個人，大部分的測試都是靠自動化完成。

因為 OceanBase 是軟體、硬體和業務集成在一起的整體優化，而當軟體、硬體和業務碰到一起的時候，經常會出現各種碎片化的小場景問題，那麼又是怎麼解決的呢？陳萌萌介紹說，當遇到這樣的場景時，就會提前把大家拉到一個釘釘群里，把需求丟到群中，技術團隊根據需求提供反饋建議，業務團隊也會反饋在試驗中遇到的問題。這些碎片化的場景和問題，很難區分到是軟體、硬體還是業務的問題，因此群里有運維、開發、業務甚至還有負責業務拓展的 BD 和負責產品的 PD，只要需要關注的人員都可以進到群里。陳萌萌透露他自己平常關注的活躍群就至少在 20 個以上，也就是至少一天發一條消息的群，他也在更多的可能十天半個月才發一條消息的技術討論群中。

以前在甲骨文公司的時候，陳萌萌說大家更習慣用郵件的慢節奏溝通方式，到了阿里系就是碎片化的溝通。首先每個人有負責的業務或技術方向，空閑的時間就會把群里的來龍去脈都過一遍。有些群是按需找人，在群里被@了就肯定會關注這些消息，如果沒有被@，就會找不是特別緊急時候再把群里的消息過一遍。雖然群很多，但是真正過群消息的時候，幾分鐘時間還是能夠把過去幾天的消息都過一遍。這樣總是能區分哪些是需要第一時間響應的，哪些可以後續持續關注的。

一般 OceanBase 團隊的工作時間是早 9 點到晚 9 點 12 個小時，但也有大促的「雙十一」、「6.18」、春節紅包壓測等緊急情況。當然，隨著 OceanBase 的發展，需要處理緊急事件的情況在減少。陳萌萌回憶，以前跟著業務團隊壓測到凌晨，甚至說半夜被揪起來的情況，會經常發生。

「我記得經歷過很多故障都挺戲劇化的：因為一旦出現一些問題以後，各方面的人都會被半夜拉起來，大家臨時被拉到一個群裡面，誰也不知道當時發生了什麼，但是每個人可能有一部分的信息，大家很快把各自的信息扔到群裡面，這樣就對出來到底發生了什麼。每個人都有點膽戰心驚，生怕自己做的那部分導致了什麼問題。」陳萌萌回憶說。「我記得有一次故障，半夜 11 點說有一個問題需要大家上線去看，一幫人包括主管都上線看問題，一直到凌晨四五點。一開始大家都在，慢慢發現問題越來越聚焦，相關的人員就上來，一直到凌晨四五點才解決問題。中間大家在群裡面各種排查信息分析，提出各種建議，雖然沒有坐在一起，但就像關在一個屋子裡面開了連夜的戰鬥會一樣。」

陳萌萌總結了阿里這種獨特的技術討論群解決問題的過程：「這是一個不停過濾信息再分析的過程。如果一開始不掌握所有信息，誰也總結不了。對完信息後，有人發現說某個地方需要關注，別的人再把相關信息加過來，慢慢連成一個邏輯。當你回頭再看群里消息的時候，這個現象特別明顯。信息一開始是散的，然後慢慢才能達成一致，最後走下去。」

當然，群里也會有熟悉各種「疑難雜症」的「老中醫」，一般是經驗比較豐富的人員，見到的問題也比較多，所以別人可能還在猜測的時候，「老中醫」就會給一個很靠譜的可能性，沿著這個可能性去看的話，發現確實可以通過這個角度去挖掘解決問題的方案。

然而，即使討論出了可能的解決方案，「大家還是挺膽戰心驚的，敲命令都是讓專門負責運維的人員去敲，這個時候的關鍵在於手不抖、別敲錯，因為萬一敲錯了那就是二次故障。所以我們都會找一個心理素質好的同事操作，大家誰也不要吱聲，看著這個同事安靜地把命令敲完。」因為不管通過群里的討論，選擇一條最保險最靠譜的操作方式，但在系統裡面直接敲命令都有可能直接動數據，敲錯一個鍵就有可能把所有數據都刪了，這是沒法挽回的，「所有人在操作的時候都不敢出氣」。

當然，每次處理完故障後，也會復盤找到以後的解決方案，最後形成知識庫也就是應急預案再固化到程序里，通過程序防止下一個錯誤。

前面提到整個 OceanBase 並沒有一個統一的產品經理，因為 OceanBase 的功能列表是對標商業資料庫。但還是會有產品開發的規劃，通常以財年為單位、雙十一為重要節點，比如某個版本必須要在下一個雙十一之前做出來並且穩定運行，再通過雙十一檢驗。「保持這樣一個節奏」，蔣志勇補充。

▌成功之道：不斷證明自己

「以前分散式系統谷歌裡面是有的，但是資料庫領域沒有一個人用到生產系統裡面。包括我們最初用 PAXOS 協議做資料庫的時候，傳統資料庫從業人員帶著原有思維看這件事，大家覺得不可思議。我們與螞蟻金服的業務方交流，告訴業務方能同時做到一致性與可用性，不丟一條數據而且做到高可用，業務方覺得不可理解，因為業務方已經習慣了傳統資料庫的方式。」馮柯在回憶 OceanBase 早期的發展時，還是很興奮當時打破了傳統技術的思維。

改變一個人的思想是非常困難的事情。OceanBase 作為資料庫領域的新進入者，優勢在於把分散式系統和資料庫結合起來。「其實 OceanBase 本身不是一個專業資料庫團隊，OceanBase 的創始人本身都不是學資料庫的，而是最早從分散式存儲開始做起，OceanBase 到很後面才真正有了 SQL 的功能。」作為傳統資料庫專家出身的馮柯說，OceanBase 最吸引他的地方在於有機會能接觸到影響幾億人的業務。OceanBase 對於傳統資料庫也不是一味模仿，而是在分散式架構方面做差異化，「我們今天不是簡單的功能模仿，每一個功能在 OceanBase 上，由於架構的不同，內涵其實是不一樣的，挑戰也不一樣。其次，今天在 OceanBase 真正上線一個業務，馬上就能服務到幾億人，這兩點是非常吸引像我這樣背景，包括從 Oracle 來的技術人員。因為 OceanBase 有非常好的應用場景。」

作為 OceanBase 的創始人，陽振坤經常強調資料庫不是被研製出來的，而是被用出來的。今天 OceanBase 如果推翻重來，或許會有更好的方案，但在發展的初期很多時候要考慮團隊的生存問題、滿足業務和場景的需要，所以當時很多的選擇是面向用戶的選擇，讓更多的業務能夠跑在 OceanBase 之上，通過這種方式來建立用戶對 OceanBase 的信任。

「如果大家當時能看見原來七年後 OceanBase 能長成這樣，我相信七年前的那個環境會好很多。但是這種如果是不存在的，很多時候你要先證明自己。」馮柯說。

楊傳輝介紹說，OceanBase 從淘寶轉到支付寶，很大程度上是因為 MySQL 可以滿足淘寶的多數業務需求。淘寶屬於電子商務類交易型業務，與支付寶的金融交易差別很大。當時淘寶電子商務交易是可以偶爾的丟失數據，採用了傳統資料庫的主備同步來實現高可用，但是主備之間是非同步的，備機與主機的數據之間落後幾毫秒都是有可能的，MySQL 主備同步模式已經能夠滿足淘寶電子商務交易。

從 2012 年底開始，OceanBase 開始慢慢支持支付寶的交易，支付寶交易屬於金融系統，不允許有任何一條數據的丟失。淘寶如果數據丟失了一條，還有一個最後的手段，就是可以查支付寶。畢竟丟失數據的概率極低，只有在極端場景下才有可能丟失數據，而且還能向支付寶查詢，支付寶就是最後的防線。2014 年，支付寶交易由 Oracle 切換成 OceanBase，實現了一條數據都不丟失，而且保證高可用、強一致。這在傳統資料庫都沒有辦法做到：既保證一條數據也不丟失，又保證數據的高可用。因為對於傳統資料庫來說，這兩個要求是相互矛盾的事情。OceanBase 創新地採用了分散式系統里的 PAXOS 的協議，第一次把這個協議用於傳統資料庫和分散式系統兩個領域的結合，並在 2014 年雙十一中得到了檢驗，後面的發展就比較順了。

蔣志勇回憶他剛來的時候，當時還是對於支付寶核心業務上 OceanBase 有很大的爭議。「2014 年雙十一的時候，爭論很激烈，最後是 CTO 當時拍板要上 10%。當時在上 1%還是上 10%這方面大家很糾結，因為畢竟雙十一 10%的流量幾乎相當於平時的全量了。當時 CTO 拍板做 10%，並且後面還挺順利。從那個時候開始，在核心業務上，大家就慢慢接受和認可 OceanBase 了。」

楊傳輝回憶當時為了趕上 2014 年雙十一的進度，時間非常緊張。上「雙十一」，就意味著在線上不能出一次問題，那時有大約近二十萬行代碼是半年之內一次性新開發的，但是上線不能出一次問題，因此對質量保證提出特別嚴格的要求。上線前做了很多容災測試、代碼檢測、設計檢測等，包括當時涉及到的所有 SQL 語句都做了全面測試。「即便是這些事情都做了，也還是有一定的運氣成分，最後 OceanBase 上線沒有出一次故障。因為當時七八月份對核心業務底層系統升級完後就不可能再升級了，後面確實一個問題都沒有出現，最後雙十一成功切了 10%的流量。」如果當時出現哪怕一次問題，可能 OceanBase 將不再存在。

▌在螞蟻，遇到更好的自己

2014 年的時候，OceanBase 團隊面臨著當年雙十一的生死大考。而馮柯也是在 2014 年加入 OceanBase 團隊的，作為一個傳統技術和商業環境出身的技術人員，馮柯在 OceanBase 經歷了從傳統企業文化到互聯網公司文化的轉型。

「我那時有很強的思維慣性，剛來 OceanBase 的時候，覺得看什麼都不爽，OceanBase 是別人寫的代碼，總覺得這裡不應該這樣做，那裡不應該那樣做。那個時候特別挑戰，也包括過去是我說了算，今天說了不算，反正是非常痛苦的一個過程。」馮柯來 OceanBase 前半年基本上處於每天無事可乾的狀態，後來主管就給他布置任務，讓他放下層級的觀念去把 OceanBase 源代碼看一遍。於是，馮柯當時就用了大概 6 個月左右的時間，看了將近 20 萬行、每個月 5 萬行左右的代碼，報了 100 多個 bug，寫了很多文檔，做了最基礎的事情。

這個過程讓馮柯在從代碼上更了解 OceanBase，能夠做更具體的事情，其次也是最重要的就是調整了心態。「我剛加入螞蟻金服的時候覺得很恐懼，覺得阿里是一個價值觀很強的公司，後來發現層級只是對你過去的一個認可，來了阿里之後就要忘了過去，從頭開始。把自己沉下去，再浮上來，你就會更加有力量。」當從代碼上真正認可了 OceanBase，把 OceanBase 當作自己的產品，就能把自己全部投入到 OceanBase 中。「現在看兩年前的我，確實變化比較大。來了阿里之後，遇見更好的自己。」

之所以說到阿里之後遇見更好的自己，這首先是要放開自己、重新清零，打破思維定勢後就能給團隊帶來非常大的幫助。馮柯發現螞蟻金服的團隊文化不像國企那樣層級就代表決定權，在螞蟻金服必須要做事情、真正拿到結果並獲得大家的認可和信任，才能做更多的事情。「大家並沒有去想你是一個 P10 或 P9，你不應該做這個事，你應該做那個事，這是我特別感觸的一點。螞蟻金服真的是一個非常專註技術、完全內部平等的文化，這跟我在之前的很多公司差別很大。」而這，正是在阿里遇到更好的自己的原因所在。

▌OceanBase 商業化：再創造新時代

「OceanBase 是真正想去做一款通用的分散式資料庫產品。產品化這點非常重要，這就要對用戶做高度集成的整體交付，而不是一堆技術拼起來。OceanBase 在架構上是真正想去做一款能夠改變目前整個商業資料庫生態或者格局的產品，我不管它未來能不能做到，但當時非常打動我，也是吸引我加入 OceanBase 的原因。」 馮柯說：「分散式是 OceanBase 的亮點，但最重要的是 OceanBase 是按照產品的思維而不是單純解決業務的問題，當時我就看明白了，OceanBase 未來肯定是要到外部發展。」

關係資料庫這個領域的理論已經比較早就成型了，多年來也沒有突破性的進展。而 OceanBase 這些年做的事情，其實是在做一個分散式的關係資料庫產品。在做產品的過程中，最大的問題是要有特別好的場景來檢驗它，從而演變成一個能夠商業化的產品。螞蟻金服最大的優勢是業務場景非常豐富，讓 OceanBase 在服務外部客戶之前，就在內部得到非常充分的鍛煉，而這些鍛煉很難通過外部用戶去獲得。

蔣志勇強調，資料庫產品化需要時間去歷練，如果抱著非常投機的心態參與就很難實現。「所以從業人員要確實對這個有興趣，並且要願意長時間堅守、慢慢打磨，把 OceanBase 從幾個人做出來的軟體，變成一個很好用的通用產品。」

從 2017 年開始，OceanBase 跟隨整個螞蟻金服的金融科技開放，開始了向傳統金融賦能的實踐過程。當然，這個過程也不是一帆風順。雖然 OceanBase 已經取得了很大的技術成就，但在外部用戶應用 OceanBase 的過程中，往往會被很多具體的小細節所「絆倒」。現在負責 OceanBase 外部業務的馮柯表示，外部客戶往往沒有螞蟻金服這麼成熟的技術體系，還處於各種傳統技術混搭的局面，在這種情況下如何把 OceanBase 在外部用戶的業務環境中落地，這都是需要具體解決的問題。

OceanBase 終於邁出了商用的一小步：OceanBase 在南京銀行正式上線，OceanBase 資料庫為南京銀行「鑫雲+」互聯網金融開放平台提供金融級分散式關係資料庫服務。而這主要取決於南京銀行的意願，「南京銀行自身有非常強的意願和情懷，把整個互聯網的核心業務完全架到 OceanBase 之上。南京銀行就像螞蟻金服內部的業務方一樣，真正與技術團隊站在了一起，包括南京銀行的很多設計都是超前的，即使目前的業務量不需要這樣設計的也會提前布局，後面有一個非常長遠的規劃。南京銀行項目為什麼成功，就是因為這一點。」 馮柯總結南京銀行的成功。「南京銀行當時是陽振坤老師去談的，南京銀行也有競標，也不只螞蟻金服一家。當時南京銀行技術負責人問了陽老師一句話，你們到底有沒有決心替換掉 Oracle，這句話撞到陽老師的槍口上了。」

陽振坤回憶 OceanBase 的整個發展歷程，「首先肯定是要滿足內部的業務需求，如果連自己的需求都滿足不了，就根本談不上做成一個真正的商用資料庫。也許 Google 吃虧在他們的業務部門比較強勢了，所以做出來的 Google Spanner 就是一個滿足自己內部需求的產品，所有的都是自定義。而 OceanBase 走了一條標準化之路，我們支持標準的資料庫介面、標準的資料庫語言，所以能夠產品化。」

從 2010 年 5 月調研、6 月 25 日立項開始，OceanBase 的目標就是傳統商業關係資料庫的更新換代產品：2012 年底支持簡單的 SQL；2014 年支持比較有限的 SQL；2016 年基本兼容了 MySQL，對 SQL 的支持開始豐富起來。這是一個由分散式到與資料庫結合的過程。接下來，OceanBase 要兼容商業資料庫。再接下來，就是要發展 OLAP 技術。

與 OLTP 技術的要求不同，OLAP 偏向大型數據分析，對於查詢處理、計劃生成、性能和調度等的要求非常高，對於分散式集群的大型查詢，怎樣通過調度把負載分配到每一個合適的節點，讓整體的吞吐率和響應時間都能達到一個比較好的平衡，都需要大量的工作。

總結 OceanBase 的成功，可以說是阿里巴巴/螞蟻金服舉全集團之力完成的「壯舉」。用楊傳輝的話說，就是阿里對技術容忍度超乎想像的高。馬雲經常講：我不懂技術，但是我尊重技術。

陽振坤回顧 OceanBase 的內部創業史，對於資料庫技術來說在螞蟻金服內部創業要遠比在公司外部創業好，因為根本找不到像螞蟻金服這樣願意把自己的內部業務拿出來當「小白鼠」。「我覺得我們這些人正好趕上了一個很好的機會，所以我就跟大家說這是千載難逢的機會，我們一定要做，而且一定能做成。」

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