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

摘要： 兩萬字長文帶你了解關於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能夠入選世界互聯網領先科技成果，能夠進入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團隊）架構師的馮柯，於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的應用，於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這樣一個劃時代的分散式資料庫，自然有寫也寫不完的研發故事，以下僅摘取幾例以體現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（下）

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎