陽振坤：數據庫自然選擇了計算機，但計算機自然並不適合數據庫

2018年6月25日，清華大學計算機科學與技術系60週年系慶系列講座第11場報告在清華大學東主樓舉行。螞蟻金服高級研究員、OceanBase負責人陽振坤在本次學術報告中發表了題爲《OceanBase每秒處理25.6萬筆支付的技術關鍵》的主題演講。

陽振坤以行業趨勢爲切入點，對螞蟻金服自研的金融級關係型數據庫OceanBase的發展歷程和技術突破點進行了深度剖析。

本文整理自演講內容：

在互聯網世界裏，存在着一種怪圈：本地企業爲了向本地人羣推銷本地產品，卻天天都在源源不斷地把廣告費輸送給境外公司。在美國，有這麼幾家巨無霸公司，諸如Google、Amazon、Facebook等，已經逐漸壟斷了歐洲和日本的互聯網應用相關市場。

而反觀中國，咱們有本身的電商網站（淘寶天貓等），本身的搜索引擎和社交應用（微信，微博等）。咱們是否能夠自信的說，咱們真的達到了國際一流的技術水平？從互聯網應用的角度來看，中國製造的應用在形態上不斷演變，不斷豐富，咱們認可本身確實已經作得比較優秀。可是，在覈心基礎部件上，咱們還有很長的路要走。

今天，從大範圍廣泛使用的角度來看，中國還不能說真正有本身的處理器，不能說真正有本身的操做系統，也不能說真正有本身的關係數據庫。或許有人會說，今天的開源生態日益繁榮，咱們徹底能夠用開源的操做系統，開源的數據庫。

OceanBase負責人陽振坤

給你們提供這樣一份數據：在手機市場上，中國每一部安卓手機不只要給國外某操做系統軟件公司繳納幾美圓到十幾美圓的專利費，還要給國外某通訊巨頭繳納手機價格百分之幾的通信及芯片的專利費。

而在金融行業，幾乎全部銀行的關鍵軟件硬件基礎設施都來自美國，服務器是IBM的，共享存儲是EMC的，數據庫軟件大部分是Oracle，剩下的少部分是IBM的DB2。咱們假設，若是某一天真的發生軍事衝突，銀行系統三年得不到技術支持和設備配件，咱們的金融業會怎樣？

努力了這麼多年，在關鍵基礎的軟件硬件設施方面，咱們仍是把本身的命脈和財富都交給了別人。

爲何要作中國本身的關係數據庫？

這既是互聯網推進的客觀需求，也是金融行業數字化轉型的必然結果。

互聯網時代的全新挑戰

在沒有互聯網的時代，不管是商場仍是銀行，關係數據庫系統的併發量很是有限，從幾10、幾百至關廣泛，幾千、幾萬以上就比較少見了。進入互聯網時代之後，併發訪問量發生了數量級的增加。2010年的雙十一，高峯期間阿里巴巴的天貓的併發訪問量已經達到幾十萬，再到去年2017年的雙十一，這個併發訪問量已經達到一千多萬。這已是一個從量變到質變的過程。

能夠說天貓雙十一所帶來的現象級的併發訪問量是源，推進了整個團隊來作這件事。
那麼另一個重要的因素，就是在傳統模式下，無論是商場仍是銀行，它的訪問量很穩定，商場/銀行擴建時有充分的時間把整個IT數據庫系統擴展開來。而現現在，咱們的網站可能上個星期訪問量仍是十萬級別的，幾天時間就可能上漲了近十倍，傳統關係數據庫系統硬件的半年左右的購買實施週期沒法適應業務的變化。

這就是互聯網時代數據庫所呈現的兩種特性，第一是併發量很是大，隨之所帶來的也是幾百上千倍的成本。第二就是負載變化劇烈，帶來伸縮性的變化。

你們都知道，2017年天貓雙11創造了新的支付記錄：25.6萬筆/秒，那麼這到底是個怎樣的概念？

簡單解釋來看，就是爲了要達到25.6萬筆的支付，數據庫須要執行4200多萬條SQL。用一個更直觀的例子，中國的五大行是中農工建交，他們每秒鐘的支付能力可能就是一萬多筆的體量甚至還不到。

這也就是說，若是支付寶採用一樣的解決方案，則須要付出大銀行十幾倍幾十倍的IT系統成本。

迴歸關係數據庫的本質：事務

數據庫之因此有價值，是由於事務。它之因此困難，也是由於事務。用華東師範大學的副校長周傲英教授的一句話來歸納，數據庫的本質就是作三件事：轉帳、記帳、訂票。

生活在今天的現實世界中，沒有任何地方能離得開關係數據庫。打電話的時候，關係數據庫在幫你計費；買火車票，買飛機票，銀行存取款，還有各類各樣的網站交易等等，在這背後其實都是關係數據庫在支撐。因此，絕不誇張的說，關係數據庫是今天整個信息社會中最關鍵，最無可替代的基礎設施。

可是，數據庫倒是個很差搞的東西。若是說數據庫中最關鍵的是事務，其最重要的就是事務的ACID特性。

• 原子性（A）：一個事務要麼所有執行，要麼不執行。好比你從取款機取錢，這個事務能夠分紅兩個步驟：改帳戶餘額，出錢。不能餘額減了，而錢沒出來。這兩步必須同時完成，要麼就不完成。
• 一致性（C）：在金融系統中，一個典型的場景就是信用卡主副卡。比方說，你和你的家人使用了主副卡，你花了一筆錢，大家的信用額度都會相應減小，若是你的家人還了一筆款，大家的信用額度都會相應增長。若是是在一臺機器上實現起來還沒那麼難，那麼若是在兩臺不一樣的機器上，這件事情就會變得很是困難。
• 隔離性（I）：事務在運行的過程當中，表現地像是系統中當前惟一運行的事務，不會由於系統中併發執行的另外一個事務而訪問到不一致的數據。
• 持久性（D）：今天惟一可以有持久性的東西，其實就是硬盤。數據中心硬盤的年故障率約爲2%-4%，因此說若是你的硬盤都壞了，你的數據還會存在嗎？

用一句話來總結來講就是：

數據庫自然選擇了計算機，但計算機自然並不適合數據庫。

數據一條不能錯，服務一秒不能停

關係數據庫在業務系統中處在一個最底層的位置。關係數據庫之因此困難，也是由於一個很是簡單的道理：數據不能錯，服務不能停。在任何業務系統中，數據庫的數據錯誤都是巨大的災難，對於金融業務，若是你的系統中止服務超過30分鐘，你恐怕須要去銀監會說明狀況。

由於有這兩個因素，更換數據庫的風險很是高，但一般卻沒有與之匹配的收益。這也是爲何像IBM、微軟這樣的後來者也沒法取代Oracle。這就致使了數據庫變成了一個門檻極高，強者恆強的領域，後來者很難居上。

OceanBase：關係數據庫的重塑者

傳統數據庫的侷限

上圖是一個很是簡單的傳統數據庫的架構示意圖。今天IOE的體系在銀行業已經根深蒂固。雖然IBM的服務器和EMC的存儲目前已經有一部分國內廠商能夠替代，可是Oracle的江湖老大地位卻無人撼動。

即便把一個數據庫的設備作到最貴最好，單個設備出故障的狀況仍是存在，好比停電。因此數據庫的系統必定須要一個備庫，而與此同時引起的另一個問題就是主備同步。

可是傳統關係數據庫在理論上卻根本作不到主備同步。若是你必定要作到同步，那麼就意味着每一筆事務都得從主庫同步到備庫，備庫確認後才能應答客戶。假如這中間網絡出現問題，或者備庫存在問題，全部的同步都會被堵塞，也就是全部的寫操做都沒法進行。

對於銀行和企業來講，這是一個生死兩難的問題，要保證同步，就面臨着業務不可用的風險。因此銀行購買可靠性更高的存儲和服務器等硬件。最好的硬件可靠性天然高，但是價錢也很是高昂。

傳統關係數據庫的另一個侷限就是分佈式數據庫的缺失。分佈式事務兩階段提交模型看起來至關美好，可是實際上一旦節點在第二階段出現故障，則事務既沒法提交也沒法回滾，只能被掛起，在實際生產系統中，這會致使數據庫的鏈接迅速被耗盡，從而使得服務中斷。

分佈式數據庫的缺失致使傳統關係數據庫沒法進行水平擴展，而只能採起垂直方式進行擴展，這不只進一步增長了成本，也限制了業務的發展。不管是主庫備庫不一致，仍是分佈式數據庫的缺失，根本的緣由是傳統關係數據庫自身高可用的缺失，即今天的傳統關係數據庫都是經過外部硬件來保證可用性，而沒有從數據庫系統內部來解決問題。

OceanBase的目標：十倍性價比，作到別人作不到的事

關係數據庫的市場是如此之特殊，OceanBase想要生存和發展，就必須在一些點上作到極致。而OceanBase給本身定的目標就是：把性價比作到傳統數據庫的十倍，而且作到別人作不到的事。

從八年前立項至今，OceanBase一直在腳踏實地的作三件事。
1）第一件事情是保證高可用的同時解決數據一致性問題。OceanBase經過把可用性作到數據庫系統內部來解決這個問題。

前面咱們分析過，高可用與主備庫數據一致的矛盾，這是一個沒法改變的客觀規律。那麼，OceanBase是如何作到的？OceanBase數據庫高可用的關鍵在於：用一主兩備或一主多備代替一主一備。主庫到備庫同步的時候也不要求同步到每一個備庫，而是同步到包括主庫在內的多數庫（超過半數），也就是說總共三個庫中若是有兩個成功了，這個事務就成功了。因此說，任何一臺機器出了問題，這個系統的可用性和數據一致性都是保證的。

以三個庫爲例，若是壞了一臺機器，每一筆事務至少會在剩下兩臺中的一臺上出現，因此整個系統可以很快的恢復起來，繼續提供服務。這樣既保證了數據一致性，又保證了整個系統的可行性。

若是萬一壞了兩臺怎麼辦？雖然同時壞兩臺機器的機率極其低，可是在實際生產中仍是可能出現的。因此，在重要的生產系統中，OceanBase用的不是三個庫，而是五個庫。這也就意味着，即便壞了一臺機器，哪怕人爲因素致使再殺掉一臺，這個系統仍然可以正常工做。

高可用和數據的一致性，OceanBase讓二者都獲得了保證。這也就是咱們說的，作別人作不到的事。OceanBase能夠跟銀行保證：少許服務器甚至機房故障不會丟失任何一筆數據，也不會中止服務，甚至人工對帳的手段也再也不須要。這也是今天銀行業很是歡迎咱們的緣由之一。

2）第二件事是提高性能，OceanBase經過原生的讀寫分離，使得整個系統性能，特別是寫的性能獲得了很大的提高，同時將成本大幅度下降。

OceanBase將新寫入的數據放在內存，使得整個寫事務（除了日誌）不須要隨機寫盤。這對性能來講有了質的提高。

可是原生的讀寫分離，實際上是有成本的。一個成本就是須要把新的修改放到內存之中，內存容量是有限的，不可能無窮無盡地寫下去。因此每隔一段時間必定要把這個內容融合到磁盤中去。

雖然本質上仍是須要把數據寫到磁盤裏，可是帶來的好處是顯著的。經過原生的讀寫分離能夠完美錯開業務的高峯期。把業務高峯期要作的事情（寫盤）先放在內存之中，那麼等過了高峯期，在平峯期和低谷期時，再把數據寫到硬盤裏去，至關於把CPU、硬盤IO錯開利用。

3）第三件事就是咱們真的把OceanBase作成了一套分佈式數據庫。

有人會說這個看起來很簡單，不就是把在一臺機器上作的事在幾臺機器上運行嗎？OceanBase幾十我的的團隊花了整整五年，作了三個大的版本，才把分佈式事務作到了現在比較完善的地步。

分佈式的意義究竟何在呢？雙十一一年就一次，對於業務量穩定的銀行和企業而言，有人以爲這個不是必要的需求。但現現在，移動支付已經融入到了每一個人的生活。一個很是廣泛的業務高峯期就真實發生在每一個工做日的中午，上班族們拿着手機支付餐費，隨着手機支付的進一步普及，這個常態的支付峯值會愈來愈高。

將來已來，砥礪前行

OceanBase Milestone

2010年6月，OceanBase正式立項；2011年，淘寶收藏夾上線；2014年，支付寶交易系統上線；2016年，支付寶帳務系統上線；2017年，OceanBase開始商業銀行推廣，至今已在多家商業銀行上線運行。

OceanBase至今已成功應用於支付寶所有核心業務：交易、支付、會員和帳務等系統，網商銀行和印度PayTM以及阿里巴巴淘寶收藏夾、P4P廣告報表等業務。從2017年開始，OceanBase開始服務外部客戶，包括南京銀行、浙商銀行、人保健康險平臺等。

下一步方向

OceanBase 2.0即將在這個夏天發佈，這是OceanBase真正把分佈式事務作的比較完善的一個版本。2.0版本中同時會在事務優化、SQL優化器上作更多提高。
同時，後續咱們但願經過人工智能/機器學習來協助用戶更好的使用數據庫，包括二級索引，SQL性能優化，故障診斷等等。咱們也使用包括RDMA在內的新技術，以便進一步提高系統的性能，下降整體的成本。

更多精彩內容歡迎關注「OceanBase」公衆號，回覆關鍵詞「交流羣」，便可加入螞蟻金服技術交流羣，快來和陽老師一塊兒探討技術吧！