436
陽振坤深度解析OceanBase如何支撐支付寶雙十一14萬/秒筆交易
談到2015年天貓雙11，912.17億之外，大家往往記住的第二個數字是“1秒鍾14萬筆訂單（刷新交易峰值世界記錄）”。可惜對於技術實踐所涉及的內容並不多。而搜索引擎中居於首位的還是知乎上關於2014年雙11的一個討論貼。
直到看到螞蟻金服平台產品技術部基礎數據部高級研究員陽振坤內部培訓程：“OceanBase如何支撐支付寶雙十一每秒十四萬筆交易”，才對其背後的技術有了更多了解，同時對困擾許久的幾個問題有了明確的解答。特別整理並分享出來。【文章已經得到陽老師的確認】
OceanBase不需要高可靠服務器和高端存儲
OceanBase是關係型數據庫，包含內核+OceanBase雲平台（OCP）。而與傳統關係型數據庫相比，最大的不同是OceanBase是分布式的，支持水平線性擴展；基於PC服務器，無高可靠服務器，無高端存儲（共享存儲）。這和一些傳統數據庫背後一定要有共享存儲是完全不同的。
現在OceanBase已經在支付寶、淘寶、天貓、一淘等多處使用。2014年雙11交易中，隻承擔了10%流量，但今年雙11中已經承擔國內交易100%流量，國際交易100%流量，會員50%流量，支付充值50%流量等。
要知道，交易多套核心係統在OceanBase之前都是某商業數據庫的，這也是業內廣為流傳的故事了。（技術細節可以參考《揭秘阿裏服務互聯網金融的關係數據庫——OceanBase》）
2015年雙11：
00:05:01：交易創建達到峰值14萬筆/秒；
00:09:02：支付達到峰值8.59萬筆/秒。
如果對這組數字無感，做個對比。Visa支付峰值是1.4萬筆/秒（實驗室測試是5.6萬筆/秒）；MasterCard實驗室測試是4萬筆/秒。
有個一直困擾業內的問題：支付為何比交易要低？交易創建時，支付寶內部就可以實現。但要支付，涉及扣款，來源可以是花唄、餘額寶和銀行渠道，如信用卡和儲蓄卡等，尤其銀行渠道方麵，其中都需要交互時間。一般來說，傳統銀行峰值多是在幾千筆每秒。
這樣的交易筆數在全球都是遙遙領先的。
當然，過程並非完全一帆風順。比如去年曾經一塊硬盤壞了，還好有容錯，自身屏蔽了。今年沒有硬盤故障，但有一個業務在壓測環節沒有發現，其查詢量極大，且隨著交易量增加而增加，每整分鍾都會有查詢產生，指向應該是備庫，但實際是卻是指向了主庫。所以技術工程師發現每個整分鍾都有交易抖動。最後采用了緊急變更的方法，將查詢調到備庫才得以解決。
數據庫有很多技術重點。但有幾點很重要，第一、第一、第一（重要的事情重複3遍）是可靠性。
先分析下傳統方式，如傳統數據庫+高端共享存儲，或冗餘方式來實現。服務器也要高可靠。所以要實現5個9，軟件、存儲、服務器都很貴，服務也貴。而為了避免不可控因素，傳統數據庫形成了主備鏡像。有三種方式：Maximize Protection，Maximize Performance、Maximize Availability，各有利弊。事實上，傳統方式的可靠性很好，但在可擴展能力、成本（性價比）上才是製約。
相比之下，PC服務器集群，性價比高、水平擴展、易於采購和維護等，亮點多多。但製約隻有一個，穩定性可用性不如高端服務器和高可靠存儲。如果說高端服務器和存儲可以做到5個9，那x86 PC服務器能做到3個9就不錯了。所以機器不可靠，但係統就必須要可靠。這就是雲計算的思路。同一數據存在多地。那麼每個事務到達超過半數庫時，少數庫故障肯定就不會影響業務。
再引用一段博客內容的分析：
- 為此，OceanBase引入了Paxos協議，每一筆事務，主庫執行完成後，要同步到半數以上庫(包括主庫自身)，例如3個庫中的2個庫，或者5個庫中的3個庫，事務才成功。這樣，少數庫(例如3個庫中的1個庫，或者5個庫中的2個庫)異常後業務並不受影響
那麼有個問題：存了3份數據，是否隻利用了三分之一的服務器？不是的，因為磁盤空間會有浪費，但是比共享存儲要少的多。而且備份服務器也是其他係統的主服務器。要實現高可靠性，這一點浪費是必須的。
傳統數據庫的版本升級是最要注意的。一些大的故障多是出於此。業內有些做法是先升級備庫，升級完成後，將主庫遷移過來。但這一過程也要打問號。因為版本升級造成數據庫問題，業內屢見不鮮。比如2013年某國有大商業銀行因為數據庫版本升級，造成業務停頓近1小時。再如2014年某國的簽證數據庫罷工（後查明是因為一個小補丁），20萬份簽證被拖延幾星期。
相對這些傳統數據庫，幾年才出一個版本，內核開發測試團隊就有千人，隻有覺得很可靠時，才會對外發布。但互聯網節奏不容許如此，所以OceanBase麵臨的挑戰更大。為了快速響應業務需求，OceanBase最初一個星期會發幾個版本，現在則是1-2周發布一個版本。
OceanBase開發之初就開始思考這個問題。即使到現在，從1個測試人員到現在十幾，OceanBase的測試團隊連人家零頭都不算。問題始終存在，辦法總要想去來——灰度升級。
詳細分析下：
- 與傳統數據庫相比，OceanBase的另外一個關鍵特征是軟件版本的灰度升級。主備方式的傳統數據庫是“單活”的，隻有主庫可執行寫事務，盡管維護升級時可以先操作備庫，操作完成後備庫變成主庫並且接受用戶訪問是一步到位的，如果新版本有問題，則業務受到影響。而OceanBase則是“多活”設計，即多個庫（3個，5個等）每個都可以有部分讀寫流量，升級時先把要升級的庫的讀寫流量切走，升級後先進行數據對比，正常後逐步引入讀寫流量(白名單，1%，5%，10%......)，一切正常並運行一段時間後再升級其他的庫。
比如出現新版本異常，趕快將新版本上的流量切走。對業務的影響是可控的。除此以外，每個事務帶64位校驗碼，每個表及每個列帶64位校驗碼，都來保證事務和表列的正確性。
OceanBase與傳統數據庫的技術區別
有三個問題值得關注。
- 為什麼傳統數據庫難以灰度升級？因為傳統數據庫備庫就是備庫，不是Active的，隻有出現問題或者升級替換時才會變成主庫。而OceanBase每個庫都是Active。
- 為什麼傳統數據庫不可以用PC服務器代替高端服務器和存儲？一方麵是一台普通PC服務器不能撐住傳統數據庫，且出現故障幾率大，另一方麵是軟件機製需要做很大更新，而傳統數據庫是將這些硬件可靠性通過高端產品來實現，而專心做SQL優化、IO優化、排序優化等。
- 為何數十年來，數據庫方麵很少有能夠挑戰某商業數據庫的統治地位？因為數據庫事務（ACID）實現非常複雜，業務對數據庫的穩定性要求極高。也因為磁盤IO瓶頸嚴重製約著數據庫的性能，用同樣的技術實現途徑，其他廠商很難超越它，而全內存數據庫成本太高。
那麼OceanBase的切入點是在哪裏？
隨著發展，現在的數據庫存儲的數據量越來越大，多是以TB來統計。但一天修改量並不大，增刪改（修改）隻是很少的一部分，比如全國人口數據庫、賬務庫、交易庫都是這樣。基於這樣的原則，OceanBase用磁盤存儲數據庫，但用內存數據庫來存儲修改數據，沒有額外成本。還消除了隨機寫磁盤，批量來寫入，非常適合SSD（固態盤）【進一步解釋下，普通磁盤最怕隨機讀，但SSD很適合。利用這一特性，OceanBase每天一次真正同步修改到磁盤上】。修改增量融合也采用了多庫異步的方式，避免了對業務的影響。要知道，以塊為單位來設計的數據庫是很難做到這一點的。
現在，OceanBase已經廣泛使用在阿裏集團的金融領域，如交易、支付、清算等。今年雙11還成功承擔了開篇時提到的任務。
要注意的是OceanBase 1.0還消除了UpdateServer單點，且正從語義+協議方麵完全兼容MySQL，DBA可以將MySQL完全替換成OceanBase，但應用層是完全感知不到的。對業務完全透明，這樣至少能將數據庫服務器減少一半。
OceanBase即將在2016年放到阿裏雲上對外提供服務。最後，技術同學們喜歡將OceanBase稱為OB。
如需轉載，請聯係雲棲社區編輯(
最後更新：2017-04-01 13:44:33