阿里雙十一數據庫技術

前言

大家都知道，雙十一的零點高峰給系統帶來的壓力，尤其是數據庫，作為整個交易系統最核心的組成部分，數據庫的性能直接決定了整個系統的穩定性。

阿里巴巴（淘寶和天貓）的核心系統全部運行在PC服務器和MySQL數據庫上，通過數據水平拆分實現了非常高的擴展性和可用性， 數據庫的容量已經不再是系統瓶頸。雙十一最重要的工作就是根據業務的壓力，準確評估出系統的容量。因為阿里數據庫的規模非常大，數據庫擴容也是一項艱巨的 工作，必須有自動化工具才能完成。我們還準備了很多應急預案，來應對一些突發的情況，并且通過不斷的演練，保證了出現問題時可以快速解決。 AliMySQL是阿里內部的MySQL分支，我們根據業務場景，對MySQL做了多項改進。同時，阿里巴巴自主研發的OceanBase數據庫，已經在 多個核心應用上使用，在雙十一中承擔了非常重要的作用。

數據庫容量

數據庫的容量評估分為兩個部分：評估業務對數據庫產生的壓力，數據庫單機所能承載的容量，根據這兩個值就可以計算出數據庫集群的規模和水位。將業務 指標換算成數據庫的指標QPS（Query Per Second，本文中的QPS不僅包括查詢，還包括插入，修改和刪除等數據庫操作）是一個非常復雜的過程，大致的思路是：首先按照業務指標評估每個應用接 口的調用量，然后再根據不同的接口調用量計算出成數據庫的指標QPS。

看似簡單，實際情況要復雜得多。淘寶的系統非常龐大，系統間的調用關系非常復雜，要分析出每個應用接口調用數據庫的QPS絕非易事。為了解決這個問 題，在阿里內部有一套鷹眼（eagleeye）系統，可以監控應用接口的調用量，調用關系，以及每個接口訪問數據庫的QPS等。借助這套系統，我們就可以 比較準確的估算出數據庫的容量。大家可以看出，評估數據庫的容量是自上而下進行的，所以，梳理應用的調用關系是非常重要的。

一般情況下，在應用層和數據庫之間，還有一層Cache，所以在評估數據庫的容量時，我們還要考慮Cache的命中率，以及Cache服務器宕機的 情況。在雙十一大促時，Cache承擔了非常大的訪問壓力，一旦命中率下降或者宕機，將會給數據庫帶來巨大的壓力。我們必須要考慮這種情況，但是過度考慮 會浪費大量的機器資源。所以，從平衡的角度出發，我們會為數據庫預留1-2臺Cache服務器宕機的容量，最高不超過Cache集群的10%。

評估出業務指標對數據庫的容量需求，我們還需要知道數據庫單機所能承載的壓力。我們采用的方法不是通過系統Load，CPU或IO利用率來評估的， 而是直接模擬真實業務來進行壓測，這樣做的好處是更真實。因為不同的應用的模型是不同的，比如查詢型、插入型、混合型、內存型、IO型等。還有很多因素會 影響數據庫的性能，比如：數據量大小，查詢復雜度，是否有熱點等。同時，機器的硬件配置也是不同的，CPU型號，內存大小，SSD還是磁盤都會顯著影響數 據庫的水位。不同應用反映在系統上的瓶頸也不同，可能是CPU，也可能是IO，也可能是網卡。我們之前就曾經碰到某個數據庫集群，CPU還很空閑，但是千 兆網卡被打滿的情況。所以根據真實的業務進行壓測，可以最真實的反映出系統的瓶頸，系統的最短板決定了數據庫的容量。

根據壓測的數據，我們就可以計算出整個集群的總容量。舉一個例子：某數據庫集群共16臺主機，單機的容量是4萬QPS，那么整個集群的容量就是64 萬QPS。假設根據業務的指標，我們估算出雙十一數據庫的壓力為48萬QPS，那么該數據庫集群的水位就是75%。根據這個思路我們開發了數據庫容量平臺 （Database Capacity Platform），可以非常直觀的了解數據庫的水位信息，水位非常直觀的反映出數據庫是否超出了容量。一般我們認為75%是安全水位，水位超過75%則 需要進行擴容。

數據庫擴容

因為雙十一和平時的壓力存在非常大的差距，所以我們需要在雙11前對數據庫集群進行擴容，必須在一個月的時間內完成，這個工作量是非常巨大的。數據 庫按照業務分為很多個集群，每個集群內由很多臺MySQL數據庫組成，數據一般按照用戶ID或商品ID水平拆分。數據庫集群擴容的類型有兩種：一種是讀寫 分離，通過增加備庫提供讀服務來提升集群的能力；另一種是水平擴容，將數據重新分布，拆分到更多臺服務器上，達到擴容數據庫集群的目的。

第一種方式比較簡單，但是因為數據庫主備存在延時，只適用于對讀一致性要求不高的場景。第二種方式需要重新分布數據，雖然比較復雜，但是理論上沒有容量的限制，我們大部分的擴容都采用這種方式。

不僅要考慮擴容，還要考慮縮減。在雙十一之后，為了保證不浪費機器資源，我們還要對集群進行縮減。如果是讀寫分離則比較簡單，直接將備庫下線即可， 但是水平擴容的方式，集群縮減的成本非常高。而且，最困難的地方在于擴容和縮減不能影響業務，必須在線進行，同時要盡量自動化，解放DBA的生產力。

集群的擴容和縮減，我們依靠一套自動化系統（DBFree）來完成，DBFree是阿里內部為MySQL量身打造的自動化運維系統，能夠快速資源快速分配、拆庫拆表拆實例、擴容和縮減。

如果沒有這套系統，要在這么短的時間內完成大量數據庫的擴容幾乎是不可能完成的任務。

數據庫預案

應急預案就是為了保護應用或數據庫制定的措施，預案分為降級和限流兩種：降級是關閉某些不重要的功能，限流是控制進入系統的流量。對于不同的數據 庫，我們都有對應的應急預案，當發生壓力超出數據庫所能提供的容量時，我們可以通過預案來保護數據庫，不至于發生雪崩（數據庫超出容量，響應時間變慢，導 致前端應用出現問題的連鎖反應）的情況。

因為數據庫是整個系統的最底層，數據庫要依賴于上層的應用來保護，以前數據庫本身是沒有自我保護能力的。今年雙十一，我們創新的提出了數據庫的自我保護和限流功能，作為數據庫的應急預案，極大提升了數據庫的穩定性。同時，應用也可以感知到這個錯誤，并作相應的處理。

數據庫新技術

AliMySQL是阿里內部的MySQL分支，不僅修復了很多bug，還根據業務場景，開發了很多新的特性，比如：并行復制，并發控制，自我保護等等。

并行復制：MySQL主備復制是單線程的，如果主庫寫入量比較大，備庫就會產生延遲。如果備庫需要提供讀服務，延遲是不能接受的。并行復制就是為了 解決這個問題而提出來的，并行復制將原來的單線程復制變為多線程復制，有效解決了主備延遲的問題。雙十一，很多數據庫的備庫都提供了讀服務，在主庫寫入壓 力很大的情況下，主備延遲非常低，并行復制功不可沒。

并發控制：這個補丁主要是解決熱點更新的問題，比如熱點商品更新庫存，秒殺，紅包等場景。當同時大量更新數據庫中的同一行時，就會產生大量的鎖等 待，數據庫的性能就會急劇下降。比如：在極端情況下，并發更新同一行，MySQL的TPS會降低到1000以下。并發控制補丁的作用通過控制并發更新的數 量，緩解了熱點更新的鎖爭用問題。經過測試，使用并發控制補丁，并發更新同一行，MySQL的TPS可以穩定在5000左右。今年雙十一，沒有發生商品超 賣的情況，并發控制補丁是幕后英雄。

自我保護：當數據庫發現性能很差的SQL或者超出系統的容量時，數據庫會進行自我保護，保證數據庫的性能和響應時間，不至于持續惡化。數據庫的自我保護是阿里巴巴數據庫團隊率先提出并應用到生產環境的，經歷了雙十一的檢驗，極大的提升了數據庫的性能和穩定性。

OceanBase

OceanBase是阿里巴巴自主研發的可擴展的關系型數據庫，實現了跨行跨表的事務，支持數千億條記錄、數百TB數據上的SQL操作。在阿里巴巴 集團下，OceanBase數據庫支持了多個重要業務的數據存儲，包括收藏夾、直通車報表、天貓評價等。截止到2013年4月份，OceanBase線上 業務的數據量已經超過一千億條，機器總數超過了1000臺，經歷了多次雙十一的考驗。

OceanBase的特性包括：分布式，可動態擴展，支持事務，支持SQL，高可用等。它結合了數據庫和NoSQL的優點，像NoSQL產品一樣， 用戶不再需要關心數據如何拆分，分布式架構，可以動態擴展。同時，又像傳統數據庫一樣，支持SQL，事務，可以保證強一致性。并且任何單點故障都不會影響 可用性。它主要包括以下組件：UpdateServer，RootServer，ChunkServer，MergeServer:

相比較各種NoSQL產品，OceanBase更傾向于傳統數據庫，因為我們大部分的應用都需要強一致性，支持事務，SQL等特性，NoSQL產品 無法滿足需要。而OceanBase又提供了比傳統數據庫更強的擴展能力，用戶不再需要關心數據的拆分規則，ChunkServer可以動態擴展。所 以，OB是一個分布式的關系型數據庫，而不是又一個NoSQL的產品。

OceanBase是阿里集團最重要的自主研發項目之一，我們還在不斷加大投入，相信未來它會在阿里集團甚至外部發揮越來越重要的作用。

壓測與演練

雙十一系統的穩定性與充分的準備工作密不可分，準備環節中最重要的兩個部分就是性能壓測與預案演練。

雙十一前，我們對每個數據庫都進行了性能壓測，我們自己開發了一個壓測工具（ MyTest）來模擬業務真實的壓力，可以非常方便的對數據庫進行壓測。同時，我們還做了一項非常特殊也是風險很大的壓測，我們會人為關閉系統中的 Cache，這時業務的壓力就會全部壓在數據庫上，這樣做可以模擬緩存失效的場景，最真實地模擬出業務對數據庫的壓力。

另一項工作是預案演練，因為整個系統的應急預案非常多，今年雙十一光數據庫的預案就有兩百多個。我們內部有一套系統對預案進行管理，并且在雙十一前 進行了多次預案演練，保證預案在緊急情況下是有效的，并且可以快速執行。比如應用降級，限流，數據庫宕機，流量切換等預案，在雙十一前都被多次演練過。 “平時多流汗，戰時少流血”，這個道理相信每個人都懂。

總結

雙十一是一個龐大的系統化的工程，通過雙十一，可以檢驗我們系統的穩定性，發現系統中的薄弱環節，并加以改進。

雙十一就像是一次年終大考，對于數據庫技術的發展和自動化運維工具都有巨大的推動作用，也是對團隊組織和能力的一種考驗。

只有經常打仗的隊伍才有戰斗力！

–EOF–

來自：http://www.hellodb.net/2014/02/taobao_1111_database.html