摘要：技術成就劃時代的分布式數據庫通過核心業務的不斷上線，螞蟻金服幫助渡過了自研基礎軟件產品最艱難的應用關。年天貓雙十一，支付寶創造了萬筆每秒支付峰值的業界新紀錄，這對于數據庫來說，意味著每秒需要同時運行萬條。

通過核心業務的不斷上線，螞蟻金服幫助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是軟件、硬件和業務集成在一起的整體優化，而當軟件、硬件和業務碰到一起的時候，經常會出現各種碎片化的小場景問題，那么又是怎么解決的呢？陳萌萌介紹說，當遇到這樣的場景時，就會提前把大家拉到一個釘釘群里，把需求丟到群中，技術團隊根據需求提供反饋建議，業務團隊也會反饋在試驗中遇到的問題。這些碎片化的場景和問題，很難區分到是軟件、硬件還是業務的問題，因此群里有運維、開發、業務甚至還有負責業務拓展的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從幾個人做出來的軟件，變成一個很好用的通用產品。”

從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的內部創業史，對于數據庫技術來說在螞蟻金服內部創業要遠比在公司外部創業好，因為根本找不到像螞蟻金服這樣愿意把自己的內部業務拿出來當“小白鼠”。“我覺得我們這些人正好趕上了一個很好的機會，所以我就跟大家說這是千載難逢的機會，我們一定要做，而且一定能做成。”

本文作者：安和林

詳情請閱讀原文