小螞蟻說：
2018年6月25日，清華大學計算機科學與技術系60週年系慶系列講座第11場報告在清華大學東主樓舉行。螞蟻金服高級研究員、OceanBase負責人陽振坤在本次學術報告中發表了題為《OceanBase每秒處理25.6萬筆支付的技術關鍵》的主題演講。
陽振坤以行業趨勢為切入點，對螞蟻金服自研的金融級關係型數據庫OceanBase的發展歷程和技術突破點進行了深度剖析。
前言
在互聯網世界裡，存在著一種怪圈：本地企業為了向本地人群推銷本地產品，卻每天都在源源不斷地把廣告費輸送給境外公司。在美國，有這麼幾家巨無霸公司，諸如Google、Amazon、Facebook等，已經逐漸壟斷了歐洲和日本的互聯網應用相關市場。
從互聯網應用的角度來看，中國製造的應用在形態上不斷演變，不斷豐富，我們承認自己確實已經做得比較優秀。但是，在核心基礎部件上，我們還有很長的路要走。
今天，從大範圍普遍使用的角度來看，中國還不能說真正有自己的處理器，不能說真正有自己的操作系統，也不能說真正有自己的關係數據庫。或許有人會說，今天的開源生態日益繁榮，我們完全可以用開源的操作系統，開源的數據庫。
OceanBase負責人陽振坤
給大家提供這樣一份數據：在手機市場上，中國每一部安卓手機不僅要給國外某操作系統軟件公司繳納幾美元到十幾美元的專利費，還要給國外某通信巨頭繳納手機價格百分之幾的通訊及芯片的專利費。
而在金融行業，幾乎所有銀行的關鍵軟件硬件基礎設施都來自美國，服務器是IBM的，共享存儲是EMC的，數據庫軟件大部分是Oracle，剩下的少部分是IBM的DB2。我們假設，如果某一天真的發生軍事衝突，銀行系統三年得不到技術支持和設備配件，我們的金融業會怎樣？
努力了這麼多年，在關鍵基礎的軟件硬件設施方面，我們還是把自己的命脈和財富都交給了別人。
為什麼要做中國自己的關係數據庫？這既是互聯網推動的客觀需求，也是金融行業數字化轉型的必然結果。
互聯網時代的全新挑戰
在沒有互聯網的時代，不論是商場還是銀行，關係數據庫系統的併發量非常有限，從幾十、幾百相當普遍，幾千、幾萬以上就比較少見了。進入互聯網時代以後，併發訪問量發生了數量級的增長。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負責人陽振坤
從八年前立項至今，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在內的新技術，以便進一步提升系統的性能，降低總體的成本。
交流社區
閱讀更多 螞蟻金服科技 的文章
