李佳琦一晚賣了100億，有位“硬漢”在背後默默發力_風聞

金磊 發自 凹非寺

量子位 報道 | 公眾號 QbitAI

“美眉，來嘍，來嘍，上鍊接！”

話音剛落。

“沒了，全沒了，都被搶光嘍！”

頭部主播李佳琦，一夜100億元銷售額這件事，着實震驚了不少人。

而經歷過這位“大魔王”雙11預售的友友們，或多或少肯定是見過剛才這種名場面了。

短短1秒不到的時間，數萬甚至更多商品瞬間被搶了個精光。

從下單到支付，那叫一個一氣呵成，卡頓一點點都得被搶購大軍甩開十萬八千里。

……

但你有沒有想過一個問題：

為什麼在這麼短時間，面對如此高流量，付款卻又是這般絲滑？

不賣關子，上答案。

因為在李佳琦瘋狂賣貨的背後，一直有位“硬漢”在默默發力。

它叫做OceanBase，是螞蟻集團自主研發的純國產數據庫。

至於它的能力，講真，讓李佳琦直播帶貨體驗變得絲滑“無感”，這都是小兒科了。

畢竟，OceanBase可是頂得住每年雙11支付、金融級場景超級大流量狂虐的那種數據庫。

經得起雙11考驗的OceanBase

先來感受一下歷年雙11成交額的恐怖增長。

光是去年的成交額，就達到了4982億元之多。

什麼概念？平均到雙11當天每秒的成交量，那就是：

每秒58.3萬筆訂單！

而在如此海量又迅猛的交易面前，數據庫就成了交易是否能夠絲滑完成的關鍵。

這是為什麼？

先來簡單科普一下數據庫在這個過程中起到的作用。

我們可以把數據庫當做是一個**“賬本”**，當一個客人在店裏買了一瓶醬油，作為店主的你，是不是得在賬本上記賬？

何時何地、誰、買了什麼、單價多少、交易是否成功、還剩多少瓶醬油……

所有與這次交易相關的信息，都得一五一十地紀錄在這個賬本中。

看似簡單的流程，但往往會出現各式各樣的問題，比如人數。

一個客人還好應付，但如果同一時間，客人一窩蜂的到店裏，擠成一團吆喝着“快點記賬”呢？

若是店裏只有零星的幾個賬本，那你只能無奈地回應：“請……排……隊……”。

再例如，即便你“奮筆疾書”，但訂單源源不斷，把整個賬本記得滿滿當當呢？

那你只能跟後邊的客人説：“抱歉，賬本滿了，沒法再交易了。”

再或者你記賬的時候寫太快了，漏掉了哪點信息，或者把信息寫串行了，那這幾筆交易可就亂套了。

……

所以，這個賬本，也就是數據庫，在整個交易過程中，就顯得尤為重要。畢竟在金融支付行業當中有一句話：

賬目是支付系統皇冠上的明珠。如果一個系統可以被應用在賬目上，那麼意味着它有能力應對所有系統。

而阿里巴巴，更準確點來説，是它使用的交易系統支付寶，所採用的數據庫，正是OceanBase。

但就像剛才提到的，像雙11這種大促，數據庫所面臨的壓力，在全球範圍來看都是數一數二的。

也就是説，即便客人、交易再多，支付寶的“賬本”也不許出現讓客人排隊、賬本不夠用，甚至賬本出錯等問題。

但仔細回憶一下，每年雙11剁手的時候，支付過程似乎都是非常絲滑無感的（除非沒搶到）。

而這，便歸功於OceanBase經過數年考驗，所沉澱下來的十八般武藝了。

整體來看，它的核心能力包括四點。

首先，是數據一致性。

這一點，不僅是對於OceanBase，對任何一個數據庫來説，都是最基礎但又是最難修煉的“功法”。

還是以醬油為例，假設它在數據庫中有2張表，分別是商品類型和商品品牌。

當商店裏進了一批醬油，那你就需要在商品類型裏插入“醬油”屬性，然而這個醬油是剛剛上市的新牌子，需要在商品品牌表裏新增對應的牌子。

但如果沒有數據一致性，那就會出現一個“沒有牌子的醬油”了。

因此，每當在事務完成的時候，必須保證所有數據都具有一致的狀態。

OceanBase便具備數據塊級實時校驗、事務級實時校驗、副本級定期校驗等特性。

而且數據一致性，必須是在任何情況下都得滿足的一點，而不是説能應付某次任務就行的那種。

為此，OceanBase的數據一致性，還具備運行連續的特點。

具體來説就是在高併發場景不會出現抖動、在極端異常場景下無損容錯，以及還內置灰度變更的能力。

其次，是極致彈性。

在雙11這種大促場景下，當天所需要的數據的容量，是平時的幾十倍，普通機房在這種量級面前是招架不住的。

而OceanBase則修煉了快速上雲、下雲的功力，這便是所謂的彈性。

當需要超大數據庫容量的時候，OceanBase可以飛速的將數據、服務部署到雲上；而當不需要這麼大容量時，就又可以飛速的從雲上撤下來。

這個過程聽起來非常簡單，但實際上對於數據庫來説，是一件非常有挑戰的事情。

不論是上雲還是下雲，絕對不可能是一個一個地“拷貝”，定然海量並行，這個過程基本涉及了接近50萬次的變更操作。

而所有的操作，絕對不能對業務產生任何的影響，是有種“一步錯便天下大亂”的感覺了。

第三，是極致容量。

剛才我們也提到，去年雙11平均每秒的成交量是58.3萬筆。

但其實這個數字對於OceanBase來説並不算什麼，因為它的真實實力，是能hold住每秒100萬筆訂單支付的那種。

這個數字對於一個數據庫來説，可能就是接近億級的QPS（每秒查詢率）。

為了應對這種難題，OceanBase採用的是兩級彈性架構。

第一級數據庫經常會採用的分庫分表，也就是從單個數據庫拆分成多個數據庫、從單張表拆分成多張表。

這樣一來，就可以把數據“打散”處理，降低每個數據庫的QPS。

除此之外，OceanBase還基於此做了一個“中間件”，它的作用就是避免重複勞動。

上述過程拆過一次，以後就交給OceanBase自動擴容就可以了。

最後，是高性能低成本。

光是數據庫能力上去還不行，還得考慮成本的問題，畢竟數據存儲和管理花費巨大，已經成為了業內不爭的事實。

而OceanBase可以説是那種“既能幹又省錢”的數據庫。

光是與去年相比，在性能提升61%的情況下，諸如LSM樹通用壓縮成本節省50%、數據編碼成本節省25%。

……

由此可見，OceanBase確實是一個經得起雙11考驗的數據庫了。

更強版本來襲，但今年沒上“戰場”

今年剛剛過去的雙11，成交額數據再創新高。

那麼問題來了：

OceanBase是否還能依舊堅挺？

答案很明顯是肯定的。

OceanBase自6月1日宣佈步入“3.0時代”後，目前已經3.2版本。

但是劃重點——今年沒用最新版！

理由很簡單：因為現在的OceanBase就已經完全能hold住了。

不過既然升到了最新版本，也是有必要了解一下更強的性能。

從數據層面來看，OceanBase3.2的性能可謂是猛增。

在相同環境和任務下，與3.1版本相比：

Sysbench OLTP 性能提升24%

BMSQL tpmC 性能提升30%以上

TPC-H 性能提升655%

而且OceanBase以前的目標可能就是如何撐住雙11，解決的是一種純粹的交易類問題。

而將來則不同，OceanBase劍指更智能和更實時。

智能化方面，就是通過AI的能力自動發現問題，而且還把診斷和決策“權利”，也一併交給OceanBase自己來處理。

以往我們看到的雙11“戰場”上，都會有眾多一線員工把守，生怕突發一些重大問題。

但以後就不一樣了，甚至身兼要職的OceanBase CTO楊傳輝都表示：

我不用去了！

這份自信，也是可見一斑了。

而在實時化方面，以往很多人會認為雙11只是一個交易的場景，但其實細看下來，它還是一個實時智能分析的場景。

因為在雙11的時候，是要對商家做分析的，以往的方式在交易完成之後會到數據倉庫裏再做分析，這就需要消耗很長時間才能得出結果。

而理想的狀態是什麼呢？當然就是交易完立即出分析結果。

而現在，這已經不是一種理想了。

OceanBase3.2把很多對商家分析的工作，整合到了一套HTAP（混合事務和分析處理）系統裏面，既可以做實時交易又可以做實時分析。

這裏需要補充解釋的是，HTAP是OceanBase主打的數據庫類型。

而目前市場主流的是OLAP（聯機實時分析）和OLTP（聯機事務處理）兩種類型。

HTAP作為“新起之秀”，不僅打破了OLAP和OLTP之間長久以來固有的隔閡，而且在複雜場景中的優勢也是顯而易見。

就目前來看，OceanBase對這條道路的選擇是持堅定不移的態度。

而從上結果來看，能hold住全球數一數二複雜場景的OceanBase，是邁出了正確的一步。

從一個收藏夾開始，走向世界

現在的OceanBase，説是發展到全球最強原生分佈式數據庫方隊也不足為過。

除了能輕鬆應對雙11這種“超高壓”場景，在全球權威的性能測試TPC-C上，也是獨佔鰲頭。

國產原生分佈式數據庫打破了巨頭Oracle、IBM等集中式數據庫，長期壟斷全球數據庫的局面。

2019年，OceanBase以6088萬tpmC的在線事務處理性能創造了世界紀錄，終結了Oracle九年的霸榜。

而時隔僅1年，又以7.07億tpmC的成績，刷新了自己的紀錄。

……

但誰又能想象，就是這樣“功成名就”的數據庫，它的起點卻是一個小小的**“收藏夾”**呢。

故事還要從2010年開始講起。

在這一年，OceanBase在淘寶正式立項，但當時的情況是卻是“一無所有”。

但唯有一點是貫穿至今的，那就是它要走的路線——分佈式系統。

簡單來講，就是把大活變成多個小活一起來搞。

而關於路線的確定，就不得不提一個人了，OceanBase創始人陽振坤。

在他看來，分佈式系統就是數據庫的未來：

相比於集羣等已有的模式，分佈式系統具備更“抗壓”、“無限大”等優勢。

項目和路線是確定了，但技術嘛，“實踐才是檢驗真理的唯一標準”。

但這也成了OceanBase邁出第一步的最大阻礙——沒人敢用。

即便陽振坤和小夥伴們，像銷售一樣“地推式”地去推廣，依舊是無濟於事。

當時的淘寶雖然在使用Oracle等數據庫時，面臨着瓶頸問題，但當時已經做出了“拆分”這樣的應對措施。

加之還要MySQL的加持，基本上平穩運行是沒有問題。

在這節骨眼上，換誰想從頭折騰一遍，又有誰敢承擔其中的風險呢？

但淘寶的收藏夾，卻成為了重要轉折點。

因為當時收藏夾團隊的一個需求，無論是Oracle或者其它數據庫，都沒有辦法解決。

簡單來説，就是商品信息在發生變更的時候，“收藏夾數據庫”和“商品數據庫”中對應的兩張表，需要做一個join的操作。

但以當時無論何種技術來看，開銷着實過大。

而陽振坤團隊卻説：I Can！

收藏夾團隊選擇信任陽振坤和他的團隊，讓他們放手一搏。

最終，憑藉着分佈式系統的優勢，收藏夾在“換骨”之後安全度過了當年的雙11。

雖説首戰告捷，也算是打出了一點名氣，但不敢換數據庫這事，依舊還沒有得到解決。

於是，當時任職阿里巴巴CTO的王堅做出了一個重要決定——把OceanBase調入支付寶。

但在支付寶，畢竟涉及到的是金錢相關的問題，絕不容出任何差池。

雖然陽振坤團隊喊出“要替換掉Oracle”的口號，但同時也直接被質疑：

你怎麼保障一分錢都丟不了？

對此，陽振坤採用了“副本”的策略（上文中提到的能力之一）。

而當時的螞蟻集團CTO魯肅，將當年雙11的**1%**的流量交給了OceanBase。

但有意思的事情發生了。

在雙11之前的壓力測試過程中，身負99%流量的Oracle一蹶不振，bug層出不窮。

每次超過90%這個門檻，就會出現問題；但OceanBase在自己“一畝三分地”的表現卻出奇的穩。

於是，魯肅也算是背水一戰，決定讓OceanBase負責的流量，從1%升到了10%。

最終，OceanBase沒有辜負厚望，順利幫助支付寶度過了當年的雙11。

而截至當時，OceanBase的版本才迭代到0.5。

就這樣，OceanBase用一次又一次的行動，證明了自己的價值，證明了分佈式數據庫的正確性。

時至今日，OceanBase已經進入第12個年頭了，陽振坤當年喊出的口號也已成真：

支付寶所有數據庫，均已替換成OceanBase！

……

若是從OceanBase的發展歷程來看，大致可以把它分為三個階段：

1.0時代 （2010-2014）：是“堅定走向分佈式架構”的時代，包括髮布了新一代分佈式引擎、實現海量存儲低成本、處理準內存引擎高性能業務。

2.0時代 （2016-2019）：是“原生分佈式數據庫”的時代，實現了永遠在線，突破容量限制無限擴展，突破地域限制單機到城市級容災能力。

3.0時代 （2020-2021）：是“混合引擎、混合部署”時代，內核架構全面升級，打破邊界，同時支持TP和AP、混合雲部署。

而到了現在，OceanBase要做的還有**“走出去”**。

第一層，是走出阿里巴巴，而且是最具挑戰、最具難度的金融業務。

例如，OceanBase通過它高可用的架構，已經幫助一些銀行的核心繫統，實現兩地三中心容災。

不僅實現了跨地域無損容災，還提升了快速適配開發的能力。

第二層，是走出國內。

畢竟在數據庫界有句話，叫做“能處理金融行業的數據庫，其它場景都能處理”。

OceanBase確實也做到了如此，已經涉足國內多個行業，幫助提升數據庫質量，完成數據化轉型。

而目前OceanBase也在把目標慢慢向國外發展，在更大的舞台、更強勁的對手較量。

最後一層，是走向開放。

截止到上個月末，OceanBase開源版本已經發布了140余天。

就在這短短的時日裏，它的開源社區已經累計了21000多用户，斬獲4200+ Star。

不僅兼容MySQL，還提供越發開放的接口、部署工具、遷移工具和數據庫運維工具供使用。

同時在人才培養方面，與高校合作開設課程、出教材、辦比賽，還完成了1000多的人才認證。

……

這，就是國產數據庫OceanBase的故事。

那麼最後，站在這樣的一個時間點，又該如何重估它呢？

套用主播們經常用的一句話，或許就是——國貨之光吧。