1、引言
OceanBase 是螞蟻金服自研的分佈式數據庫，在其 9 年的發展歷程裏，從艱難上線到找不到業務場景瀕臨解散，最後在雙十一的流量考驗下浴火重生，成爲螞蟻金服全部核心系統的承載數據庫。這一路走來的艱辛和故事，螞蟻金服高級研究員、OceanBase 團隊負責人陽振坤將爲你娓娓道來。
什麼是OceanBase數據庫？
是阿里巴巴集團自主研發的分佈式關係型數據庫，融合傳統關係型數據庫強大功能與分佈式系統的特點，具備持續可用、高度可擴展、高性能等優勢。廣泛應用於螞蟻金服、網商銀行等金融級核心系統。 在2015年雙11承載了螞蟻核心鏈路100%的流量，創下了交易、支付每秒支付峯值的新紀錄，在功能、穩定性、可擴展性、性能方面都經歷過嚴格的檢驗。
2、關於作者
陽振坤：博士、YOCSEF榮譽委員。
1984年進入北京大學，先後獲得數學學士、碩士以及計算機博士學位後留校，1997年破格晉升爲教授，1999年成爲北京大學首批“長江學者獎勵計劃”特聘教授之一；
先後獲得北京市科學技術進步獎一等獎、國家科學技術進步獎一等獎（排名第四）、第六屆中國青年科技獎、北京市五四青年獎等；
曾先後擔任方正研究院副院長、北大計算機研究所副所長、聯想研究院首席研究員、微軟亞洲研究院主任研究員、百度高級科學家等；
現擔任淘寶研究員，主持淘寶海量數據庫系統的研究和開發。
3、相關文章
《阿里技術分享：深度揭祕阿里數據庫技術方案的10年變遷史》 《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》 《現代IM系統中聊天消息的同步和存儲方案探討》 《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》 《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》 《一套高可用、易伸縮、高併發的IM羣聊架構方案設計實踐》
4、數據庫：技術和市場的“死亡之谷”
數據庫在每個人的生活裏無處不在，不管是通訊、交通、金融行業，抑或是每天大家都在接觸的互聯網，所有這些業務的背後都是數據庫在支撐。
▲ 螞蟻金服 OceanBase 團隊負責人陽振坤
數據庫經歷了近半個世紀的發展，在理論上很成熟，在技術應用上也已經非常成熟了。
但是數據庫偏偏有一個特別高的門檻，原因是數據庫有三條特別苛刻的要求：
1）事務須併發處理： 數據庫要支持事務，所有人都希望用最小的處理資源，做到最大價值的事情。所以事務持續要做大量的併發處理；
2）數據一條不能錯： 一個數據庫如果數據錯了，就永遠沒有機會了。對於使用者而言，如果你會錯一條，你就有可能會錯一千、一萬條，這是沒有公司願意承擔的風險；
3）服務片刻不能停： 通訊系統、列車系統，甚至飛機航行系統的背後都是數據庫在支撐，這些系統一旦啓動，一分一秒都是不能終止的。
上面提到的這三條要求，任何兩個其實都好滿足。但是大家仔細想一想，這三個要求如果要同時滿足，就會變得極其困難。
同時，數據庫又是一個巨大的市場，對國家、對整個社會都非常重要。這就導致很多國家、很多企業都想做也正在做這件事，但是結果大家都做到了同一個思路上。後來者都成了先行者的模仿者，那麼這個模仿的代價就會變得很大。
今天作爲一個後來者，你再去做這麼一套數據庫系統的時候，就真的很難說清楚你與先行者相比有多大的優勢。這也就造成了強者恆強、寡頭壟斷的局面，後來者很難居上。
數據庫同樣也有開源這條路徑，比如大家都瞭解的 MySQL。開源是免費的，對於很多對成本敏感的公司而言開源數據庫成爲了替代商業數據庫的另一種選擇。
那麼在面對數據庫的“死亡之谷”這樣的困境下，爲什麼我們還去花這麼多錢，投入這麼多設備，花這麼多年時間和人力再去做一個數據庫，究竟它的意義在哪兒？它又能夠產生多大的經濟價值？
既然有了開源的數據庫，阿里巴巴和螞蟻金服還要做這麼一個商業數據庫產品，其實這裏面是有本質原因的。很多人知道阿里巴巴今天已經 全面去 IOE：去掉了 Oracle 數據庫、IBM 小型機、 EMC 存儲。那麼很多人就在想，能不能在其他的行業，在鐵路、交通，電信、政府這些行業推而廣之，全部完成去 O 的進程呢？這個答案是否定的。
因爲像阿里巴巴發展的這一套系統是基於 MySQL 的開源數據庫，跟商業數據庫在功能和性能上其實是有很大差距的。阿里巴巴當時在用它的時候，有很多事情數據庫是做不了的，那麼這些做不了的事情當時就放在應用軟件裏做。所以阿里巴巴在數據庫和應用軟件上都投入了很大的技術力量。這套系統拿到外部業務去用是不能徹底解決問題的。本質上這套系統是服務於阿里巴巴的專用系統，而不是一個通用的系統。
那麼有人會問，在我的企業裏，如果真的想去掉 IOE，該怎麼辦？你同樣要投入兩撥人，一撥人要去做數據庫，針對你的企業的需求來做相應的修改；還有一撥人要去做應用系統。但是問題是並不是所有的企業都像阿里巴巴有這麼多優秀的技術人員，這套東西其實很難去直接推廣應用。
所以，從一開始我們做 OceanBase 的目標就是——我們不想只做一個專用的系統，要做就一定要做一個通用的系統。我們希望今後 OceanBase 能夠服務於各行各業，再也不需要企業投入幾十幾百甚至幾千個人去改造、去重新做一套業務系統。
5、OceanBase 的機遇與創新
當時做 OceanBase 數據庫一個最根本性的原因就是需求的變化。因爲這麼一套基礎系統，如果背後沒有需求的變化，從 0 到 1 自己做出來基本是不可能的。
2010 年春夏之際，我來到了阿里巴巴。去了之後發現當時有兩個因素影響了阿里巴巴關係數據庫的應用。
一個因素是併發，數據庫它是按照併發量來賣錢的。說直接點，就是按照處理器來賣錢。之所以要買這麼多處理器就是因爲業務有這麼大的需求。那麼傳統的業務比如商場，一個商場就那麼幾個收銀臺，它是一個相對穩定而且比較小的併發量，大多數情況就是幾十幾百的併發量。
▲ 陽振坤分享經驗心得
隨着互聯網的高速發展，阿里巴巴天貓雙 11 幾乎完全改變了過去行業內相對穩定的併發量，突破了幾百萬人甚至是千萬人的同時在線購買。這個併發量跟過去的傳統業務場景相比是幾個數量級的增長，按照這個數量級去買商業數據庫，沒有一家企業買得起。
還有一個因素，當時我們叫它建站，其實就是搭建一個數據庫。過去建一個商場，建一個銀行的分店，這個週期是非常長的，有足夠的時間來規劃 IT 業務系統。互聯網業務是等不了的，就像當時 OceanBase 接的第一個業務給到我們的時間就是最多一個星期。現實是一個星期的時間根本連小型機的安裝調試都完不成。
原來的模式已經完全無法支撐互聯網快速發展的業務。所以這兩個需求的變化，是催生我們自己來做數據庫的很關鍵的因素。
6、OceanBase 關鍵性的技術革新
當時我找了幾個同事商量這個事情，我跟大家說，我們是天時地利人和都趕上，這件事情除非是被拍死掉，否則我們是肯定要把它做成的。這個過程真的非常艱辛，我們花了差不多五年的時間，才真正讓 OceanBase 有了關鍵的應用。
過去做數據庫的公司，不管是國內還是國外，大家都是爲了做數據庫而做數據庫，那麼最後結果就是所有做傳統數據庫的廠商，大家的方案都很像。
因爲數據庫有很成熟的理論和工程的方法，那麼如果我們按照以往的原則做過去，結果肯定也是一樣的。所以，其實我們走了另外一條路——做分佈式。最早做這個東西可能都不叫數據庫，它更像是一個分佈式系統，但是支持了事務的特性。這條路後來被證明確實是具有特別大的價值和意義。
當時我們在做 OceanBase 的時候，首先確定了幾件事情。第一件事就是我們要做分佈式，因爲我們的業務要建站，不做分佈式靠大型機和小型機是不可能做得到的。
另外一件事是成本，什麼東西最便宜，量最大最主流的東西最便宜，它就是 PC 服務器。小型機少則幾十萬，多則幾百萬，PC 服務器頂多就是幾千幾萬塊的成本。
第三個要解決的就是可靠性問題。大家對數據庫的期望是永不宕機，永遠不出問題。可是 PC 服務器到處都有，性價比也非常好，但是不容忽視的是它的故障率高。普通 PC 服務器它遠遠達不到數據庫所要求的年可靠性五個九的要求。對普通 PC 服務器而言，差的可能是兩個或者三個數量級，所以我們得首先把這個問題解決掉。我們用的就是分佈式的辦法來解決。
我們運用的是分佈式的一致性協議，直白一點就是一個多數派的選舉和投票協議。同時，我們把修改的增量直接放在內存裏，每次要查詢的時候，把內存硬盤的數據做一個 merge，那麼每天在業務相對的低谷期，再把內存中的數據整理回硬盤去。
做到了這幾件事情，這個系統就有了很好的性價比，我們的成本比傳統的數據庫至少低一個數量級，你只需要用普通的 PC 機，不需要用昂貴的硬件設施。同時，擴展能力會也變得很好。
7、OceanBase 的第一個業務：淘寶收藏夾
理想看起來很美好，但是現實特別骨感。這個項目剛啓動的時候，我們好不容易纔找到了幾個人，人手是嚴重不足的。另外一個更大的挑戰是時間：在做 OceanBase 數據庫之前，我去找我的老闆，他說給你 兩年時間 如果能把一個數據庫做出來就可以。當時我心裏想兩年雖然對於做數據庫來說時間確實太短，但是這兩年對於那時候的我們而言已經足夠支撐起最初的想法了。
技術最終還是需要通過業務落實下去，所以我找了一批業務方，花了很長時間跟對方溝通，最後終於有一個業務願意用我們的數據庫。當時他給我的時間期限是——兩個星期。
當時我就傻了，兩個星期要做個數據庫，這可怎麼辦？後來跟業務的同學反覆討論，最後他們同意說，你們先做個 demo 出來。於是我們就花了兩個月吭哧吭哧的做了一個 demo 出來。他們看了以後覺得比較滿意，後來這個事情就一直堅持做下去了。
最後，我記得是到了第八個月的時候，系統上線了。這個業務就是現在大家都在用的——淘寶收藏夾，這是 OceanBase 的第一個業務。如果沒有這個業務，我們現在也活不下來。
▲ 淘寶收藏夾業務
那麼這個業務到底有什麼特殊的地方？每個人都用過淘寶收藏夾，每次你打開收藏夾的時候，數據庫在背後其實做了很多事情：我們以單個商品爲例，它需要到一個叫商品庫的地方，逐條紀錄覈對，看看商品有沒有下架，有沒有參與促銷，有沒有參加其他的返點活動等等。
假如你收藏了 100 多件商品，它就要進去一條條的取出來看。本質上來講，這就意味着一百多次的隨機 IO。那麼當很多人同時來看的時候，其實一個 IO 就被放大了幾百倍，這時候有多少個硬盤都不夠用。
當時他們已經用了幾十臺服務器了，按照業務的預估，第二年他們要買 400 臺機器，第三年的數量都不敢想象。當時我們想了一個辦法——我們做了一個 寬表，確切的講應該稱爲 物化視圖。
▲ 淘寶收藏夾的寬表
首先我們把每個用戶收藏的信息聚集起來，這樣可以減少 IO，然後把收藏的商品放在這個列表裏。但是我們怎麼避免去訪問一百多次 IO 呢？我們的辦法就是找到一個時間點，當時是設定在每天晚上凌晨兩點。在這之前，我們就把這些信息全部 merge 到硬盤，然後從兩點開始，我們把新的修改都放在內存裏面。
所以每到兩點的時候，我們把兩點之前所有的信息都合到這張表裏，那麼這張表裏的信息在兩點整的時候是準確的，這時候我們不需要去訪問商品庫。兩點之後的修改，包括商品庫的修改是在內存裏進行的，這時候如果要看這些商品有哪些修改，商品只需訪問內存中的更新即可。
所以其實我們就是通過這樣一個手段，把每次收藏夾的展示，由原來的一百多次 IO 變成了一次。我們一下子就把淘寶收藏夾業務的整個 IO 降下來了。當時 OceanBase 確實是幫助業務實際解決了他們的問題，使得業務能夠更好的快速的發展。業務是一定要發展的，所以只有我們真正能夠解決他們的問題，我們這些做基礎系統做底層的人，才能活下去。
▲ 淘寶收藏夾架構圖
這是當時給淘寶收藏夾做的一個架構，中間是一個做修改的服務器，所有的修改都在這一臺機器上進行。旁邊的機器是基線數據，就是分片切片以後，放到周圍這一圈進行。所以當時我們就用這個看上去很簡陋的一個方案來真正解決了淘寶收藏夾的問題。
當時收藏夾用了這個方案之後，服務器的數量從原來預計的第二年要用幾百臺，最後其實只用了差不多二十幾臺服務器，就把整個問題解決掉了。
8、OceanBase 0.3-0.4 版本：團隊面臨解散
從淘寶收藏夾項目之後，我們陸陸續續也做了不少項目，但是沒有一個項目能像淘寶收藏夾這樣對業務有明顯的價值和貢獻。
從那之後的整整兩年，我們找不到對 OceanBase 數據庫而言特別有價值的業務。那兩年對於我們而言特別特別困難，甚至整個團隊隨時面臨着解散。
2012 年底，公司把我們從淘寶調到支付寶，當時預估到支付寶在數據庫方面所面對的挑戰更大，後來證明確實如此。即使是這樣，當時仍然還處在一個非常困難的時期。到了支付寶一年多的時間，我們仍然很難找到新的業務，或者說價值比較大的業務來證明我們的價值。
9、OceanBase 0.5 版本：成功抗住 10% 流量
2013 年的夏天，支付寶希望全面去掉 IOE——去掉 IBM 的小型機，Oracle 的數據庫和 EMC 的存儲。當時面臨了一個問題，就是去掉之後是可以用 MySQL 來代替 Oracle，但是 MySQL 的主備鏡像其實是做不到主備完全一致的。
這個時候我們意識到：OceanBase 的機會來了。因爲我們可以通過分佈式的選舉跟投票來做，哪怕硬件本身不可靠，我們也能保證數據的不丟失。傳統數據庫本質上是藉助硬件的可靠性，也就是硬件需要達到五個九的可靠性來實現高可用的。就算出了故障，它的數據也能救得回來。但是這種手段需要非常高的成本，同時沒有足夠的擴展能力。
銀行雖然有很高的可用性，但是它的高可用性是用很高的硬件成本換來的。我們建議一定要淘汰這些高可靠的硬件，因爲他們的成本實在太高了。一旦真的使用了高性能，高性價比的 PC 服務器，那麼你就不可能再花那麼多錢去買高端的硬件。
所以我當時心裏很明白，如果這件事情我們做不成，這個項目就只有死路一條。
那麼，OceanBase 到底如何做到主備完全一致的呢？理論上我們也沒有辦法說完全做到主庫備庫的一致。我們用了另外一個辦法：主庫還是主庫，還是需要它快速的做事務，但同時主庫還要把事務的日誌同步給至少兩個備庫。兩個備庫中至少有一個收到了，那麼加上它自己就超過了半數，或者我們叫多數派。當多數的節點收到了這個事務，並且把它持久化到硬盤了，我們就認爲這個事務是成功的。
所以這時候任何一臺機器壞掉，每筆事務在剩下兩臺機器裏面至少一臺存在。所以說即使主庫突然壞掉，另外兩臺機器經過握手，它們再選舉出一個新的主庫，那麼肯定可以繼續工作下去，同時可以保證數據是沒有損失的。
2014 年的時候，我們在會議室裏討論 支付寶交易庫的上線，當時吵得面紅耳赤，爭論了很久別人就是不願意上 OB。他們原來的交易、支付系統全都在 Oracle 上，當時的 Oracle 無論是在穩定性、可靠性還是性能方面，肯定比 OceanBase 要好得多。所以沒有人願意用。
最後，在 魯肅（螞蟻金服 CTO） 的力挺下決定切給 OceanBase 1% 的流量試試。因爲那幾年業務發展的太快，當時 Oracle 的共享存儲已經扛不住這個流量，按照當時的業務流量去做壓測的時候，幾分鐘就要壞一塊盤。最後發現，把業務切掉 10%，才能勉強扛得住。所以那一年的雙 11 就把 10% 的流量切到了 OceanBase。OceanBase 也成功扛過去了那一年的雙 11。
10、OceanBase 1.0 版本：唯一支持分佈式事務的商業數據庫
但是其實在 0.5 這個版本上線的時候，我們心裏非常清楚，這個版本是臨時的。我們當時選擇做多數派協議的時候，還是用了原來的想法，每個集羣還是中間有一箇中心節點。這個事情一定不會是長久持續下去的，我們知道這個一定會遇到問題。所以當時其實交易庫還沒有完全上線，我們就已經啓動了 1.0 版本的開發。
2014 年到 2016 年，整整兩年的時間，我們投入了 40 多個人，全部投在 OceanBase 1.0 版本的開發上。整整兩年，這 40 多個人沒幹任何別的事情。所有的線上問題，版本修改、升級都是我們調出來的五個同學全部扛下來的。
有人會問什麼樣的因素讓這麼多人做了兩年才能把這個版本做出來？這個版本里面我們主要做的一件事就是分佈式。
如果你問分佈式事務有這麼難嗎？我可以自豪地回答你：今天的商業數據庫裏有且只有一個是能夠支持分佈式事務的，它就是 OceanBase。
OceanBase 通過分佈式的一致性協議做到了系統的高可用性，就是說哪怕我們今天用的是比較廉價的，可靠性比較低的 PC 服務器，但是我們的可用性其實會變得更高。因爲單機的故障我們完全能夠自動的容忍掉，而且我們做到了現在的數據做不到的一件事情——哪怕主庫出故障，我們能夠保證數據沒有任何損失。
今天的銀行每年國家都要求他們至少做一次消防演習，銀行要到最前端的網關把交易紀錄撈出來覈對，把這些賬對平了，備庫才能繼續服務。我們今天根本沒有這個問題，主庫出故障了，也就是幾十秒以後，新的主庫就會被選出來。因爲只要剩下的機器超過半數，他們互相之間會通過握手把數據補齊，很快就能工作。其實這 30 秒大部分還是消耗在確定主庫是否真的有故障。
所以，我們用不可靠的硬件反而做到了更高的可用性，而且做到了數據真正的一致。
傳統的數據庫因爲涉及到共享存儲，共享存儲是一個單一的設備，你只能放在一個機房。所以一旦那個機房出現了故障，你就只能靠備庫容災把系統恢復起來。
OceanBase 通過“三地五中心”部署實現城市級故障自動無損容災。比方說相當於你一共寫了五份日誌，放在三個不同的城市裏。任何一個城市哪怕出故障，比方說杭州斷網了，那麼剩下的依然超過半數，這個系統還是可以恢復工作的。這也是原來的傳統數據庫，不管想什麼辦法，都做不到的事情。
▲ 2018年 9 月 20 日雲棲大會 ATEC 主論壇現場剪光纜實況
前段時間，大家可能也看到了雲棲大會的新聞。螞蟻金服副 CTO 胡喜在 ATEC 主論壇現場模擬挖斷支付寶近一半服務器的光纜。結果只過了 26 秒，模擬環境中的支付寶就完全恢復了正常。而這場 26 秒自斷服務器現場演示的技術核心其實正是基於 OceanBase 的三地五中心架構方案。
2017 年，天貓雙 11 中螞蟻金服的全部核心系統，包括很多業務系統都放在了 OceanBase 上。去年我們創造了 25.6 萬筆 / 秒 支付峯值的世界紀錄，這下面還有一個數據，就是說我們爲了要執行這 25.6 萬筆的支付，執行了 4200 萬條 SQL。
11、新的歷史機遇：走出去
所以從今天來看，OceanBase 在過去的歷史進程中面臨了一個個新的機遇，無論是處理器、操作系統還是數據庫，這些都是非常大的挑戰。
從 2016 年底，我們就開始做準備，OceanBase 一定要走出去。從我們成立的第一天起，團隊裏的每個成員的目標都是一致的：我們不是想做一個數據庫只是給自己用，我們要做一個數據庫真的去推動整個社會的進步，能夠讓整個社會的生產力發生變化。
所以，2017 年我們正式開始服務於外部，最早的兩家客戶是 浙商銀行 和 南京銀行，我們現在的客戶要多很多。從內部的應用到真正走出去服務於外部，真的是一個很大的挑戰，是一件很困難的事情。
回想這八年多來，OceanBase 走過的路：開始的頭兩三年，我們真的每天都在掙扎，每分每秒都在想着怎麼能讓自己活下來。到了 2013、2014 年，我們終於找到了一個真正的立足點，就是支付寶的交易庫。然後我們接着花了整整兩年的時間，真正在 OceanBase 1.0 版本把分佈式做出來。在接下來的一到兩年時間裏，我們把支付寶的核心業務全部搬到 OceanBase 上。
關係數據庫確實是個門檻很高的東西，但是凡事有利有弊。門檻高意味着我們進來很難，別人進來一樣難。我們集中精力在做事務處理這一塊，它的門檻是很高，很不容易進去，但我們恰恰有這個機會能進去。我們費了很大的力氣跨進來了，別人可能費了全部力氣也進不來。
現在回想起來，能夠把最早的一些想法一些創新變成產品，真的是非常辛苦或者說非常痛苦的一條道路。但是我們做的所有事情其實還是從業務、從客戶中出發，只有技術真的能夠落到生產中去，落到用戶中去纔是真正有價值的，否則你做得再好也是一個空中樓閣。
到了今天，當我們走出阿里巴巴，走出螞蟻金服再來看，發現當你做的事情能夠提供十倍性價比的時候，其實真的有機會去顛覆一個產業，重新塑造一個行業。