厲害了，螞蟻金服！創造了中國本身的數據庫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.一、0.二、0.三、0.四、0.5這一系列的版本，主要是早期爲了服務當時已有的阿里系業務；另外一條線是從2012年開始構想的、徹底從雲時代架構從新設計的分佈式數據庫OceanBase 1.0系列，2013年開始總體設計、2014年中旬抽出資源正式投入開發、2015年末開發完成，後又經歷了1.0、1.一、1.二、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致使再次宕機，直到週五晚上八、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是軟件、硬件和業務集成在一塊兒的總體優化，而當軟件、硬件和業務碰到一塊兒的時候，常常會出現各類碎片化的小場景問題，那麼又是怎麼解決的呢？陳萌萌介紹說，當遇到這樣的場景時，就會提早把你們拉到一個釘釘羣裏，把需求丟到羣中，技術團隊根據需求提供反饋建議，業務團隊也會反饋在試驗中遇到的問題。這些碎片化的場景和問題，很難區分到是軟件、硬件仍是業務的問題，所以羣裏有運維、開發、業務甚至還有負責業務拓展的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的內部創業史，對於數據庫技術來講在螞蟻金服內部創業要遠比在公司外部創業好，由於根本找不到像螞蟻金服這樣願意把本身的內部業務拿出來當「小白鼠」。「我以爲咱們這些人正好遇上了一個很好的機會，因此我就跟你們說這是百年不遇的機會，咱們必定要作，並且必定能作成。」

本文做者：安和林

詳情請閱讀原文