近十年，隨著云計算帶來的變革，傳統的 IOE 架構對于企業運營成本的影響以及對未來業務發展的制約逐漸加劇。

[[226338]]

尤其是互聯網的大規模、高并發、實時在線、大型網絡優化等新興需求，使得為傳統 IT 環境設計的 Oracle 數據庫越來越難以處理互聯網公司愈加大規模的數據量。

因此，面向超大規模互聯網公司的分布式計算環境而重新開發的關系型數據庫 OceanBase 應運而生。

作為螞蟻金服自研的分布式關系型數據庫，OceanBase 從 2008 年阿里提出“去IOE”想法，到 2017 年螞蟻金服全面實現“去IOE”，經歷過許多難以想象的磨礪，也創下了許多影響國內外的成就。

本文將深入 OceanBase，回溯其研發過程與研發方法論。

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

以下僅摘選幾個典型案例作為說明：

結合業務，整體優化軟硬件

螞蟻金服基礎數據部（OceanBase 團隊）負責 SQL 相關方向開發工作的陳萌萌介紹說，以前數據庫技術更多偏向軟件層，硬件層有專業人員、專業技術和專業的公司來解決硬件本身的穩定性或容災等問題。

但是在螞蟻金服這邊更多是軟硬結合的方案，OceanBase 軟件從設計之初就考慮了硬件層面不穩定、分布式系統的特征，從而去做以前數據庫不會做的優化工作。

以前的數據庫優化根本不會考慮到底層的硬件損壞、機器宕掉、網絡斷網、天災人禍不確定性問題，而今天 OceanBase 無時無刻不在考慮這些問題。

“以前做軟件開發，先假設底層的硬件沒有問題，而只需要把上層軟件邏輯做好就行了，現在我們是整體的軟硬件考慮。”

以數據庫的查詢優化技術來講，比如傳統的銀行柜臺，通過人工窗口提供服務，用戶的主要時間花在與人工窗口打交道等方面，對于數據庫的快慢體會不那么敏感。

但螞蟻金服是互聯網應用，數據庫隨時的一個抖動或查詢執行時間變慢了一點，用戶馬上就能直接感受到。

這與傳統應用場景差異很大，如果數據庫的一個查詢從一毫秒變到了五毫秒，傳統數據庫不會認為這是件大事。

但是互聯網應用下，多出來的四毫秒可能被放大成為幾百毫秒甚至一兩秒，一旦出現這樣的時延，用戶體驗馬上就變差了。

“我們每天都在做特別精細的事情，生怕一毫秒變成五毫秒這種事情出現，因此做了很多精確防御。”

螞蟻金服基礎數據部（OceanBase 團隊）研究員楊傳輝進一步解釋：數據庫查詢優化器本身是近似解，基本上不存在最優解，優化的目標就是逼近最理想的情況。

在傳統應用場景下可以允許優化結果差幾個毫秒甚至更多，但是在互聯網場景下就很難接受這么大的差異，所有的優化效果都要精確到幾個毫秒以內。

例如：每一次在支付寶付款，點擊一下付款按鈕，背后的數據庫可能要執行一兩百次數據庫的 SQL 查詢，優化器要為每一個查詢生成一個需要做的優化執行計劃。

如果優化器在某一個場景下犯了一個錯誤，每個查詢多出了 5 毫秒，那么整個鏈路就會多 500 毫秒，用戶在按下付款按鈕的時候發現交互速度有可能變慢了。

如果再加上可能不止做支付——比如買商品后下單再要支付——這幾個鏈路加在一起就有可能慢幾百毫秒甚至上到秒級，這對用戶來說就已經不能接受了。

還有地鐵的刷臉或者刷支付寶進站的場景。如果用戶站在閘機前面半天刷不出來，那就不光是體驗問題了，有可能會引來連鎖麻煩，后面人也會被堵起長龍。這些現實的挑戰都要求 OceanBase 反應精確、迅速。

楊傳輝告訴我們，從關鍵業務系統的數據鏈路梳理上來看，一兩百條 SQL 是最普通的一次交易了，如果涉及到支付渠道不一樣，SQL 執行的次數就會更多。

因為螞蟻金服本身是分布式的系統，所面臨一個很大的挑戰是對底層的基礎組件包括網絡要求非常高。

如果網絡出現了問題，就會對整個服務產生影響。因此 OceanBase 不僅要對數據庫層做優化，還對網絡、磁盤、操作系統等軟硬件層都要做很精確的優化。

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

螞蟻金服基礎數據部（OceanBase 團隊）SQL 組負責人蔣志勇從事 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 系統 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 個人去看監控就會得出 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 是軟件、硬件和業務集成在一起的整體優化，而當軟件、硬件和業務碰到一起的時候，經常會出現各種碎片化的小場景問題，那么又是怎么解決的呢？

陳萌萌介紹說，當遇到這樣的場景時，就會提前把大家拉到一個群里，把需求丟到群中，技術團隊根據需求提供反饋建議，業務團隊也會反饋在試驗中遇到的問題。

這些碎片化的場景和問題，很難區分到是軟件、硬件還是業務的問題，因此群里有運維、開發、業務甚至還有負責業務拓展的 BD 和負責產品的 PD，只要需要關注的人員都可以進到群里。

每個人有負責的業務或技術方向，空閑的時間就會把群里的來龍去脈都過一遍。

有些群是按需找人，在群里被 @ 了就肯定會關注這些消息，如果沒有被 @，就會找不是特別緊急時候再把群里的消息過一遍。

雖然群很多，但是真正過群消息的時候，幾分鐘時間還是能夠把過去幾天的消息都過一遍。這樣總是能區分哪些是需要第一時間響應的，哪些可以后續持續關注的。

一般 OceanBase 團隊的工作時間是早 9 點到晚 9 點 12 個小時，但也有大促的“雙十一”、“6.18”、春節紅包壓測等緊急情況。

當然，隨著 OceanBase 的發展，需要處理緊急事件的情況在減少。陳萌萌回憶，以前跟著業務團隊壓測到凌晨，甚至說半夜被揪起來的情況，會經常發生。

“我記得經歷過很多故障都挺戲劇化的。因為一旦出現一些問題以后，各方面的人都會被半夜拉起來，大家臨時被拉到一個群里面，誰也不知道當時發生了什么。但是每個人可能有一部分的信息，大家很快把各自的信息扔到群里面，這樣就對出來到底發生了什么。每個人都有點膽戰心驚，生怕自己做的那部分導致了什么問題。”

陳萌萌回憶說：“我記得有一次故障，半夜 11 點說有一個問題需要大家上線去看，一幫人包括主管都上線看問題，一直到凌晨四五點。一開始大家都在，慢慢發現問題越來越聚焦，相關的人員就上來，一直到凌晨四五點才解決問題。中間大家在群里面各種排查信息分析，提出各種建議，雖然沒有坐在一起，但就像關在一個屋子里面開了連夜的戰斗會一樣。”

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

當然，群里也會有熟悉各種“疑難雜癥”的“老中醫”，一般是經驗比較豐富的人員，見到的問題也比較多。

所以別人可能還在猜測的時候，“老中醫”就會給一個很靠譜的可能性，沿著這個可能性去看的話，發現確實可以通過這個角度去挖掘解決問題的方案。

然而，即使討論出了可能的解決方案，“大家還是挺膽戰心驚的，敲命令都是讓專門負責運維的人員去敲，這個時候的關鍵在于手不抖、別敲錯，因為萬一敲錯了那就是二次故障。所以我們都會找一個心理素質好的同事操作，大家誰也不要吱聲，看著這個同事安靜地把命令敲完。”

因為不管通過群里的討論，選擇一條最保險最靠譜的操作方式，但在系統里面直接敲命令都有可能直接動數據，敲錯一個鍵就有可能把所有數據都刪了，這是沒法挽回的，“所有人在操作的時候都不敢出氣”。

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

整個 OceanBase 并沒有一個統一的產品經理，因為 OceanBase 的功能列表是對標商業數據庫。

但還是會有產品開發的規劃，通常以財年為單位、雙十一為重要節點，比如某個版本必須要在下一個雙十一之前做出來并且穩定運行，再通過雙十一檢驗。“保持這樣一個節奏”，蔣志勇補充。

未來展望：用時間歷練、用現實考驗

蔣志勇強調，數據庫產品化需要時間去歷練，如果抱著投機的心態參與就很難實現。

螞蟻金服最大的優勢是業務場景非常豐富，讓 OceanBase 在服務外部客戶之前，就在內部得到充分鍛煉，而這些鍛煉很難通過外部用戶去獲得。

從 2017 年開始，OceanBase 跟隨整個螞蟻金服的金融科技開放，開始了向傳統金融賦能的實踐過程。

負責 OceanBase 外部業務的馮柯表示：“分布式是 OceanBase 的亮點，但最重要的是 OceanBase 是按照產品的思維而不是單純解決業務的問題，未來肯定是要到外部發展。”

如今，OceanBase 已從金融級分布式關系數據庫服務為起點，邁出了商用的一小步。

承受住時間的歷練和現實的考驗后，團隊有信心將 OceanBase 從一個軟件變成一款通用產品。

作者：吳寧川

簡介：“云科技時代”創始人。職業生涯起步于《中國計算機報》，曾任副主編一職。采訪過 Oracle 全球 CEO、VMWare 全球 CEO、ARM 全球 CEO、亞馬遜云全球 CTO、微軟全球研究院院長、華為 CIO、京東 CTO、IBM 大中華區董事長、阿里云 CEO等高管。