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