談到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》）
<b>2015</b><b>年雙</b><b>11</b><b>：</b>
<b>00:05:01</b><b>：交易建立達到峰值</b><b>14</b><b>萬筆</b><b>/</b><b>秒；</b>
<b>00:09:02</b><b>：支付達到峰值</b><b>8.59</b><b>萬筆</b><b>/</b><b>秒。</b>
如果對這組數字無感，做個對比。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。
雲栖社群歡迎所有有志于技術分享的夥伴加入。如需轉載，請聯系雲栖社群編輯(http://yq.aliyun.com/)