• 1
  • 2
  • 3
  • 4
  • 5
mysql數據庫問題 首 頁  ?  幫助中心  »  數據庫  »  mysql數據庫問題
深度解析OceanBase
發布日期:2016-5-2 22:5:1

  談到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之前都是某商業數據庫的,這也是業內廣為流傳的故事了。

  (1)2015年雙11:

  (2)00:05:01:交易創建達到峰值14萬筆/秒;

  (3)00:09:02:支付達到峰值8.59萬筆/秒。

  若對這組數字無感,做個對比。Visa支付峰值是1.4萬筆/秒(在實驗室測試是5.6萬筆/秒);MasterCard實驗室測試是4萬筆/秒。

  但是現在有個一直困擾業內的問題:支付為何比交易要低?交易創建時,支付寶內部就可以實現。但是要支付,涉及扣款,來源可以是余額寶、花唄與銀行渠道,比如信用卡和儲蓄卡等,尤其銀行渠道方面,其中都需要交互時間。一般來說,傳統銀行峰值多是在幾千筆每秒。

  這樣的交易筆數在全球都是遙遙領先的。

  當然,過程并非完全一帆風順。例如去年曾經一塊硬盤壞了,還好有容錯,自身屏蔽了。今年沒有硬盤故障,但是有一個業務在壓測環節沒有發現,其查詢量極大,且隨著交易量增加而增加,每整分鐘都會有查詢產生,指向應該是備庫,但是實際是卻是指向了主庫。因此技術工程師發現每個整分鐘都有交易抖動。最后采用了緊急變更的方法,將查詢調到備庫才得以解決。

  數據庫有很多技術重點。但有幾點很重要,第一是可靠性。

  先分析下傳統方式,如傳統數據庫+高端共享存儲,或冗余方式來實現。服務器也要高可靠。所以要實現5個9,軟件、存儲、服務器都很貴,服務也貴。而為了避免不可控因素,傳統數據庫形成了主備鏡像。有三種方式:

  (1)Maximize Protection

  (2)Maximize Performance

  (30Maximize Availability

  上面三種方式各有利弊。事實上,傳統方式的可靠性很好,但是在可擴展能力、成本(性價比)上才是制約。

  相比之下,PC服務器集群,性價比高、水平擴展、易于采購和維護等,亮點多多。但制約只有一個,穩定性可用性不如高端服務器和高可靠存儲。如果說高端服務器和存儲可以做到5個9,那x86 PC服務器能做到3個9就不錯了。所以機器不可靠,但系統就必須要可靠。這就是云計算的思路。同一數據存在多地。那么每個事務到達超過半數庫時,少數庫故障肯定就不會影響業務。

  再引用一段博客內容的分析,如下所示:

  為此,OceanBase引入了Paxos協議,每一筆事務,主庫執行完成后,要同步到半數以上庫(包括主庫自身),例如3個庫中的2個庫,或者5個庫中的3個庫,事務才成功。這樣,少數庫(例如3個庫中的1個庫,或者5個庫中的2個庫)異常后業務并不受影響

  如圖1所示:


  圖1

  那么現在有個問題:存了3份數據,是否只利用了三分之一的服務器?不是的,由于磁盤空間會有浪費,但是比共享存儲要少的多。而且備份服務器也是其他系統的主服務器。要實現高可靠性,這一點浪費是必須的。

  二、版本升級是數據庫故障最大發生處

  傳統數據庫的版本升級是最要注意的。一些大的故障多是由于這樣。業內有些做法是先升級備庫,升級完成后,將主庫遷移過來。但是這一過程也要打問號。由于版本升級造成數據庫問題,業內屢見不鮮。例如2013年某國有大商業銀行因為數據庫版本升級,造成業務停頓近1小時。再如2014年某國的簽證數據庫罷工(后查明是因為一個小補丁),20萬份簽證被拖延幾星期。

  相對這些傳統數據庫,幾年才出一個版本,內核開發測試團隊就有千人,只有覺得很可靠時,才會對外發布。但是互聯網節奏不容許如此,因此OceanBase面臨的挑戰更大。為了快速響應業務需求,OceanBase最初一個星期會發幾個版本,現在則是1-2周發布一個版本。

  OceanBase開發之初就開始思考這個問題。即使到現在,從1個測試人員到現在十幾,OceanBase的測試團隊連人家零頭都不算。問題始終存在,辦法總要想去來——灰度升級。

  我們來詳細分析下:

  與傳統數據庫相比,OceanBase的另外一個關鍵特征是軟件版本的灰度升級。主備方式的傳統數據庫是“單活”的,只有主庫可執行寫事務,盡管維護升級時可以先操作備庫,操作完成后備庫變成主庫并且接受用戶訪問是一步到位的,如果新版本有問題,則業務受到影響。而OceanBase則是“多活”設計,即多個庫(3個,5個等)每個都可以有部分讀寫流量,升級時先把要升級的庫的讀寫流量切走,升級后先進行數據對比,正常后逐步引入讀寫流量(白名單,1%,5%,10%......),一切正常并運行一段時間后再升級其他的庫。如下圖所示:


  圖2


  圖3


  圖4

  例如出現新版本異常,趕快將新版本上的流量切走。對業務的影響是可控的。另外,每個事務帶64位校驗碼,每個表及每個列帶64位校驗碼,都來保證事務與表列的正確性。

  三、OceanBase與傳統數據庫的技術區別

  OceanBase與傳統數據庫(如mysql)的技術區別,有三個問題值得關注,如下所示。

  (1)為什么像mysql這樣的傳統數據庫難以灰度升級?因為傳統數據庫備庫就是備庫,不是Active的,只有出現問題或者升級替換時才會變成主庫。而OceanBase每個庫都是Active。

  (2)為什么傳統數據庫不可以用PC服務器代替高端服務器和存儲?一方面是一臺普通PC服務器不能撐住傳統數據庫,且出現故障幾率大,另一方面是軟件機制需要做很大更新,而傳統數據庫是將這些硬件可靠性通過高端產品來實現,而專心做SQL優化、IO優化、排序優化等。

  (3)為何數十年來,數據庫方面很少有能夠挑戰某商業數據庫的統治地位?由于數據庫事務(ACID)實現非常復雜,業務對數據庫的穩定性要求極高。也因為磁盤IO瓶頸嚴重制約著數據庫的性能,用同樣的技術實現途徑,其他廠商很難超越它,而全內存數據庫成本太高。

  那么OceanBase的切入點是在哪里?

  隨著發展,現在的數據庫存儲的數據量越來越大,多是以TB來統計。但是一天修改量并不大,增刪改(修改)只是很少的一部分,比如賬務庫、全國人口數據庫、交易庫都是這樣?;谶@樣的原則,OceanBase用磁盤存儲數據庫,但是用內存數據庫來存儲修改數據,沒有額外成本。還消除了隨機寫磁盤,批量來寫入,非常適合SSD(固態盤)【進一步解釋下,普通磁盤最怕隨機讀,但SSD很適合。利用這一特性,OceanBase每天一次真正同步修改到磁盤上】。修改增量融合也采用了多庫異步的方式,避免了對業務的影響。我們要知道,以塊為單位來設計的數據庫是很難做到這一點的。

  目前,OceanBase已經廣泛使用在阿里集團的金融領域,比如支付、交易、清算等。今年雙11還成功承擔了開篇時提到的任務。

  要注意的是OceanBase 1.0還消除了UpdateServer單點,且正從語義+協議方面完全兼容MySQL,DBA可以將MySQL完全替換成OceanBase,但是應用層是完全感知不到的。對業務完全透明,這樣至少能將數據庫服務器減少一半。

  OceanBase即將在2016年放到阿里云上對外提供服務。最后,技術同學們喜歡將OceanBase稱為OB。

什么行业的讲师最赚钱 捕鱼达人3手游下载 二肖中特开奖结果 加拿大快乐8开奖连接 棋牌龙王捕鱼 单机四人麻将免费版 旧版千炮街机金蟾捕鱼 手机北京麻将下载 2018长期投资股 皇家棋牌游戏? 宁夏11选五遗漏数据