2018 年，雙 11 迎來了十周年。十年間，依賴于迅速崛起的互聯(lián)網(wǎng)技術(shù)以及各項(xiàng)新興技術(shù)的沉淀，阿里巴巴締造了全球數(shù)字經(jīng)濟(jì)時(shí)代的第一“操作系統(tǒng)”。

[[248748]]

 

在這個(gè)操作系統(tǒng)上，讓全球消費(fèi)者和商家買、賣、逛、聽、看、游得順心、放心、舒心。

十年間，阿里巴巴的技術(shù)同學(xué)和全球開發(fā)者們，一起把互聯(lián)網(wǎng)前沿技術(shù)轉(zhuǎn)化為全球消費(fèi)者、全球數(shù)字經(jīng)濟(jì)參與者可以感知的便利。

如今，它已不僅僅是全球消費(fèi)者的狂歡節(jié)，更是名副其實(shí)的全球互聯(lián)網(wǎng)技術(shù)的演練場。

從“雙 11 的技術(shù)”到“技術(shù)的雙 11”，每一次化“不可能”為“可能”的過程，都是阿里人對技術(shù)的不懈追求。

在第十個(gè)雙 11 來臨之際，有幸邀請到參與多年雙 11 備戰(zhàn)的核心技術(shù)大牛——雙11技術(shù)保障部大隊(duì)長、數(shù)據(jù)庫事業(yè)部研究員張瑞，通過這篇萬字長文，帶領(lǐng)大家回顧雙 11 這十年來數(shù)據(jù)庫領(lǐng)域的技術(shù)變遷。

十年使命：推動中國數(shù)據(jù)庫技術(shù)變革

再過幾天，我們即將迎來第十個(gè)雙 11。過去十年，阿里巴巴技術(shù)體系的角色發(fā)生了轉(zhuǎn)變，從雙 11 推動技術(shù)的發(fā)展，變成了技術(shù)創(chuàng)造新商業(yè)。

很多技術(shù)通過云計(jì)算開始對外輸出，變成了普惠的技術(shù)，服務(wù)于各個(gè)行業(yè)，真正做到了推動社會生產(chǎn)力的發(fā)展。

這十年，阿里巴巴數(shù)據(jù)庫團(tuán)隊(duì)一直有一個(gè)使命：推動中國數(shù)據(jù)庫技術(shù)變革。從商業(yè)數(shù)據(jù)庫到開源數(shù)據(jù)庫再到自研數(shù)據(jù)庫，我們一直在為這個(gè)使命而努力奮斗。

 

如果將阿里數(shù)據(jù)庫發(fā)展歷史分為三個(gè)階段的話，分別是：

• 2005 年-2009 年：商業(yè)數(shù)據(jù)庫時(shí)代。
• 2010 年-2015 年：開源數(shù)據(jù)庫時(shí)代。
• 2016 年-至今：自研數(shù)據(jù)庫時(shí)代。

商業(yè)數(shù)據(jù)庫時(shí)代就是大家所熟知的 IOE 時(shí)代，后來發(fā)生了一件大事就是“去 IOE”。

通過分布式數(shù)據(jù)庫中間件 TDDL、開源數(shù)據(jù)庫 AliSQL(阿里巴巴的 MySQL 分支)、高性能 X86 服務(wù)器和 SSD，并通過 DBA 和業(yè)務(wù)開發(fā)同學(xué)的共同努力，成功地替換了商業(yè)數(shù)據(jù)庫 Oracle、IBM 小型機(jī)和 EMC 高端存儲，從此進(jìn)入了開源數(shù)據(jù)庫時(shí)代。

[[248749]]

 

去 IOE 帶來了三個(gè)重大的意義：

• 解決了擴(kuò)展性的問題，讓數(shù)據(jù)庫具備了橫向擴(kuò)展(彈性)的能力，為未來很多年雙11零點(diǎn)交易峰值打下了很好的基礎(chǔ)。
• 自主可控，我們在 AliSQL 中加入了大量的特性，比如：庫存熱點(diǎn)補(bǔ)丁，SQL 限流保護(hù)，線程池等等，很多特性都是來源于雙 11 對于數(shù)據(jù)庫的技術(shù)要求，這在商業(yè)數(shù)據(jù)庫時(shí)代是完全不可能的。
• 穩(wěn)定性，原來在商業(yè)數(shù)據(jù)庫時(shí)代，就如同把所有的雞蛋放在一個(gè)籃子里(小型機(jī))，去 IOE 之后不僅僅解決了單機(jī)故障，更是通過異地多活的架構(gòu)升級讓數(shù)據(jù)庫跨出了城市的限制，可以實(shí)現(xiàn)數(shù)據(jù)庫城市間的多活和容災(zāi)，大大提升了系統(tǒng)的可用性。

進(jìn)入 2016 年，我們開始自研數(shù)據(jù)庫，代號 X-DB。大家一定會問：為什么要自研數(shù)據(jù)庫?有以下幾個(gè)原因：

• 我們需要一個(gè)能夠全球部署的原生分布式數(shù)據(jù)庫，類似于 Google Spanner。
• 雙 11 的場景對數(shù)據(jù)庫提出了極高的要求：在雙 11 零點(diǎn)需要數(shù)據(jù)庫提供非常高的讀寫能力。

數(shù)據(jù)庫使用 SSD 來存儲數(shù)據(jù)，而數(shù)據(jù)存在明顯的冷熱特性，大量冷的歷史數(shù)據(jù)和熱的在線數(shù)據(jù)存放在一起，日積月累，占用了大量寶貴的存儲空間，存儲成本的壓力越來越大。

• 我們經(jīng)過認(rèn)真評估后發(fā)現(xiàn)，如果繼續(xù)在開源數(shù)據(jù)庫基礎(chǔ)上進(jìn)行改進(jìn)已經(jīng)無法滿足業(yè)務(wù)需求。
• 新的硬件技術(shù)的出現(xiàn)，如果說 SSD 的大規(guī)模使用和 X86 服務(wù)器性能的極大提升推動了去 IOE 的進(jìn)程，那么NVM非易失內(nèi)存，F(xiàn)PGA 異構(gòu)計(jì)算，RDMA 高速網(wǎng)絡(luò)等技術(shù)將第二次推動數(shù)據(jù)庫技術(shù)的變革。

 

伴隨著每一年的雙 11 備戰(zhàn)工作，機(jī)器資源的準(zhǔn)備都是非常重要的一個(gè)環(huán)節(jié)。如何降低雙 11 的機(jī)器資源成本一直是阿里技術(shù)人不斷挑戰(zhàn)自我的一個(gè)難題。

第一個(gè)解決方案就是使用云資源，數(shù)據(jù)庫從 2016 年初開始就嘗試使用高性能 ECS 來解決雙 11 的機(jī)器資源問題。

通過這幾年的雙 11 的不斷磨練，2018 年雙 11，我們可以直接使用公有云 ECS，并通過 VPC 網(wǎng)絡(luò)與阿里巴巴集團(tuán)內(nèi)部環(huán)境組成混合云，實(shí)現(xiàn)了雙 11 的彈性大促。

第二個(gè)方案就是在線離線混部，日常讓離線任務(wù)跑在在線(應(yīng)用和數(shù)據(jù)庫)的服務(wù)器上，雙 11 大促在線應(yīng)用使用離線的計(jì)算資源，要實(shí)現(xiàn)這種彈性能力，數(shù)據(jù)庫最核心要解決一個(gè)技術(shù)問題就是：存儲計(jì)算分離。

存儲計(jì)算分離后，數(shù)據(jù)庫可以在雙 11 使用離線的計(jì)算資源，從而實(shí)現(xiàn)極致的彈性能力。通過使用云資源和混部技術(shù)，可以最大程度降低雙 11 交易峰值帶來的成本。

 

雙 11 備戰(zhàn)中另外一個(gè)重要的技術(shù)趨勢就是：智能化。數(shù)據(jù)庫和智能化相結(jié)合也是我們一直在探索的一個(gè)方向，比如 Self-driving Database 等。

2017 年，我們第一次使用智能化的技術(shù)對 SQL 進(jìn)行自動優(yōu)化，2018 年，我們計(jì)劃全網(wǎng)推廣 SQL 自動優(yōu)化和空間自動優(yōu)化，希望可以使用這些技術(shù)降低 DBA 的工作負(fù)擔(dān)，提升開發(fā)人員效率，并有效提升穩(wěn)定性。

相信未來，在雙 11 的備戰(zhàn)工作中，會有越來越多的工作可以交給機(jī)器來完成。

 

我從 2012 年開始參加雙 11 的備戰(zhàn)工作，多次作為數(shù)據(jù)庫的隊(duì)長和技術(shù)保障部總隊(duì)長，在這么多年的備戰(zhàn)工作中，我也經(jīng)歷了很多有意思的故事，在這里分享一些給大家。

2012 年：我的第一次雙 11

2012 年是我的第一次雙 11，在此之前，我在 B2B 的數(shù)據(jù)庫團(tuán)隊(duì)，2012 年初，整個(gè)集團(tuán)的基礎(chǔ)設(shè)施團(tuán)隊(duì)都合并到了技術(shù)保障部，由振飛帶領(lǐng)。

我之前從來沒有參加過雙 11，第一年參加雙 11 后羿(數(shù)據(jù)庫團(tuán)隊(duì)的負(fù)責(zé)人)就把隊(duì)長的職責(zé)給了我，壓力可想而知。

那時(shí)候備戰(zhàn)雙 11 的工作非常長，大概從 5、6 月份就開始準(zhǔn)備了，最重要的工作就是識別風(fēng)險(xiǎn)，并準(zhǔn)確評估出每個(gè)數(shù)據(jù)庫的壓力。

我們需要把入口的流量轉(zhuǎn)換為每個(gè)業(yè)務(wù)系統(tǒng)的壓力 QPS，然后我們根據(jù)業(yè)務(wù)系統(tǒng)的 QPS 轉(zhuǎn)換為數(shù)據(jù)庫的 QPS。

2012 年還沒有全鏈路壓測的技術(shù)，只能靠每個(gè)業(yè)務(wù)系統(tǒng)的線下測試，以及每個(gè)專業(yè)線隊(duì)長一次又一次的開會 Review 來發(fā)現(xiàn)潛在的風(fēng)險(xiǎn)。

可想而知，這里面存在巨大的不確定性，每個(gè)人都不想自己負(fù)責(zé)的業(yè)務(wù)成為短板，而機(jī)器資源往往是有限的，這時(shí)，就完全靠隊(duì)長的經(jīng)驗(yàn)了，所以，每個(gè)隊(duì)長所承擔(dān)的壓力都非常巨大。

我記得當(dāng)年雙 11 的大隊(duì)長是李津，據(jù)說他當(dāng)時(shí)的壓力大到無法入睡，只能在晚上開車去龍井山頂，打開車窗才能小憩一會。

而我，由于是第一年參加雙 11，經(jīng)驗(yàn)為零，完全處于焦慮到死的狀態(tài)，幸好當(dāng)年有一群很靠譜的兄弟和我在一起。

他們剛剛經(jīng)歷了去 IOE 的洗禮，并且長期與業(yè)務(wù)開發(fā)浸淫在一起，對業(yè)務(wù)架構(gòu)和數(shù)據(jù)庫性能如數(shù)家珍，了若指掌。

通過他們的幫助，我基本摸清了交易整套系統(tǒng)的架構(gòu)，這對我未來的工作幫助非常大。

經(jīng)過幾個(gè)月緊張的準(zhǔn)備，雙 11 那天終于到來了，我們做好了最充分的準(zhǔn)備，但是一切都是那么地不確定。

我們懷著忐忑不安的心情，當(dāng)零點(diǎn)到來的時(shí)候，最壞的情況還是發(fā)生了：庫存數(shù)據(jù)庫的壓力完全超過了容量，同時(shí) IC(商品)數(shù)據(jù)庫的網(wǎng)卡也被打滿了。

我記得很清楚，當(dāng)時(shí)我們看著數(shù)據(jù)庫上的監(jiān)控指標(biāo)，束手無策。這里有一個(gè)小細(xì)節(jié)：由于我們根本沒有估算到這么大的壓力，當(dāng)時(shí)監(jiān)控屏幕上數(shù)據(jù)庫的壓力指標(biāo)顯示超過了 100%。

正在這時(shí)，技術(shù)總指揮李津大喊一聲：“大家都別慌!”這時(shí)我們才抬頭看到交易的數(shù)字不斷沖上新高，心里才稍微平靜下來。

事實(shí)上，對于 IC 數(shù)據(jù)庫網(wǎng)卡被打滿，庫存數(shù)據(jù)庫超過容量，都超出了我們的預(yù)期，所以最終我們什么預(yù)案也沒做，就這樣度過了零點(diǎn)的高峰。

因?yàn)檫@些原因，2012 年的的雙 11 產(chǎn)生了大量的超賣，給公司帶來了很大的損失。

那一年的雙 11 后，庫存、商品、退款和相應(yīng)數(shù)據(jù)庫的同學(xué)，為了處理超賣導(dǎo)致的問題，沒日沒夜加了兩周的班。

而且，我周圍很多朋友，都在抱怨高峰時(shí)的用戶體驗(yàn)實(shí)在太糟糕了。我們下決心要在第二年的雙 11 解決這些問題。

2013 年：庫存熱點(diǎn)優(yōu)化和不起眼的影子表

2012 年的雙 11 結(jié)束后，我們就開始著手解決庫存數(shù)據(jù)庫的性能提升。

庫存扣減場景是一個(gè)典型的熱點(diǎn)問題，即多個(gè)用戶去爭搶扣減同一個(gè)商品的庫存(對數(shù)據(jù)庫來說，一個(gè)商品的庫存就是數(shù)據(jù)庫內(nèi)的一行記錄)，數(shù)據(jù)庫內(nèi)對同一行的更新由行鎖來控制并發(fā)。

我們發(fā)現(xiàn)當(dāng)單線程(排隊(duì))去更新一行記錄時(shí)，性能非常高，但是當(dāng)非常多的線程去并發(fā)更新一行記錄時(shí)，整個(gè)數(shù)據(jù)庫的性能會跌到慘不忍睹，趨近于零。

當(dāng)時(shí)數(shù)據(jù)庫內(nèi)核團(tuán)隊(duì)做了兩個(gè)不同的技術(shù)實(shí)現(xiàn)：一個(gè)是排隊(duì)方案，另一個(gè)是并發(fā)控制方案。

兩者各有優(yōu)劣，解決的思路都是要把無序的爭搶變?yōu)橛行虻呐抨?duì)，從而提升熱點(diǎn)庫存扣減的性能問題。

兩個(gè)技術(shù)方案通過不斷的完善和 PK，最終都做到了成熟穩(wěn)定，滿足業(yè)務(wù)的性能要求，最終為了萬無一失，我們把兩個(gè)方案都集成到了 AliSQL(阿里巴巴的 MySQL 分支)中，并且可以通過開關(guān)控制。

最終，我們通過一整年的努力，在 2013 年的雙 11 解決了庫存熱點(diǎn)的問題，這是第一次庫存的性能提升。

在這之后的 2016 年雙 11，我們又做了一次重大的優(yōu)化，把庫存扣減性能在 2013 年的基礎(chǔ)上又提升了十倍，稱為第二次庫存性能優(yōu)化。

2013 年堪稱雙 11 歷史上里程碑式的一年，因?yàn)檫@一年出現(xiàn)了一個(gè)突破性的技術(shù)-全鏈路壓測。

我非常佩服第一次提出全鏈路壓測理念的人-李津，他當(dāng)時(shí)問我們：有沒有可能在線上環(huán)境進(jìn)行全仿真的測試?

所有人的回答都是：不可能!當(dāng)然，我認(rèn)為這對于數(shù)據(jù)庫是更加不可能的，最大的擔(dān)心是壓測流量產(chǎn)生的數(shù)據(jù)該如何處理，從來沒聽說過哪家公司敢在線上系統(tǒng)做壓測，萬一數(shù)據(jù)出現(xiàn)問題，這個(gè)后果將會非常嚴(yán)重。

我記得在 2013 年某天一個(gè)炎熱的下午，我正在庫存數(shù)據(jù)庫的問題中焦頭爛額的時(shí)候，叔同(全鏈路壓測技術(shù)負(fù)責(zé)人)來找我商量全鏈路壓測數(shù)據(jù)庫的技術(shù)方案。

就在那個(gè)下午，我們兩個(gè)人討論出了一個(gè)“影子表”的方案，即在線上系統(tǒng)中建立一套“影子表”來存儲和處理所有的壓測數(shù)據(jù)，并且由系統(tǒng)保證兩套表結(jié)構(gòu)的同步。

但是，我們對這件事心里都沒底，我相信在雙 11 的前幾周，沒有幾個(gè)人相信全鏈路壓測能夠落地，我們大部分的準(zhǔn)備工作還是按照人工 Review+線下壓測的方式進(jìn)行。

但是，經(jīng)過所有人的努力，這件事竟然在雙 11 前兩周取得了突破性進(jìn)展，當(dāng)?shù)谝淮稳溌穳簻y成功的時(shí)候，所有人都覺得不敢相信。

最后，雙 11 的前幾個(gè)晚上，幾乎每天晚上都會做一輪全鏈路壓測，每個(gè)人都樂此不疲，給我留下的印象實(shí)在太深刻了。

但這個(gè)過程，也并不是一帆風(fēng)順，我們壓出了很多次故障，多次寫錯(cuò)了數(shù)據(jù)，甚至影響了第二天的報(bào)表，長時(shí)間高壓力的壓測甚至影響了機(jī)器和 SSD 的壽命。

即便出現(xiàn)了如此多的問題，大家依然堅(jiān)定地往前走，我覺得這就是阿里巴巴與眾不同的地方，因?yàn)槲覀兿嘈潘钥匆姟?/p>

事實(shí)也證明，全鏈路壓測變成了雙 11 備戰(zhàn)中最有效的大殺器。

 

如今，全鏈路壓測技術(shù)已經(jīng)成為阿里云上的一個(gè)產(chǎn)品，變成了更加普惠的技術(shù)服務(wù)更多企業(yè)。

2015 年：大屏背后的故事

2015 年，我從數(shù)據(jù)庫的隊(duì)長成為整個(gè)技術(shù)保障部的總隊(duì)長，負(fù)責(zé)整個(gè)技術(shù)設(shè)施領(lǐng)域的雙 11 備戰(zhàn)工作，包括 IDC、網(wǎng)絡(luò)、硬件、數(shù)據(jù)庫、CDN，應(yīng)用等所有技術(shù)領(lǐng)域。

我第一次面對如此多的專業(yè)技術(shù)領(lǐng)域，對我又是一次全新的挑戰(zhàn)。但是，這一次我卻被一個(gè)新問題難倒了：大屏。

2015 年，我們第一次舉辦天貓雙 11 晚會，這一年晚會和媒體中心第一次不在杭州園區(qū)，而是選擇在北京水立方，媒體中心全球 26 小時(shí)直播。

全球都在關(guān)注我們雙 11 當(dāng)天的盛況，需要北京杭州兩地協(xié)同作戰(zhàn)，困難和挑戰(zhàn)可想而知!

大家都知道對媒體直播大屏來說最最重要的兩個(gè)時(shí)刻，一個(gè)是雙 11 零點(diǎn)開始的時(shí)刻，一個(gè)是雙 11 二十四點(diǎn)結(jié)束的時(shí)刻，全程要求媒體直播大屏上跳動的 GMV 數(shù)字盡可能的不延遲。

那一年我們?yōu)榱颂嵘本┧⒎浆F(xiàn)場的體驗(yàn)及和杭州總指揮中心的互動，在零點(diǎn)前有一個(gè)倒計(jì)時(shí)環(huán)節(jié)，連線杭州光明頂作戰(zhàn)指揮室，逍遙子會為大家揭幕 2015 雙 11 啟動，然后直接切換到我們的媒體大屏，所以對 GMV 數(shù)字的要求基本上是零延遲，這個(gè)挑戰(zhàn)有多大不言而喻!

然而，第一次全鏈路壓測時(shí)卻非常不盡人意，延時(shí)在幾十秒以上，當(dāng)時(shí)的總指揮振飛堅(jiān)決的說：GMV 第一個(gè)數(shù)字跳動必須要在 5 秒內(nèi)。

既要求 5 秒內(nèi)就拿到實(shí)時(shí)的交易數(shù)字，又要求這個(gè)數(shù)字必須是準(zhǔn)確的，所有人都覺得這是不可能完成的任務(wù)。

當(dāng)時(shí)，導(dǎo)演組也提了另外一個(gè)預(yù)案，可以在雙 11 零點(diǎn)后，先顯示一個(gè)數(shù)字跳動的特效(不是真實(shí)的數(shù)字)。

等我們準(zhǔn)備好之后，再切換到真實(shí)的交易數(shù)字，但對媒體大屏來說所有屏上的數(shù)據(jù)都必須是真實(shí)且正確的(這是阿里人的價(jià)值觀)。

所以我們不可能用這個(gè)兜底的方案，所有人想的都是如何把延遲做到 5 秒內(nèi)，當(dāng)天晚上，所有相關(guān)的團(tuán)隊(duì)就成立一個(gè)大屏技術(shù)攻關(guān)組，開始封閉技術(shù)攻關(guān)。

別看一個(gè)小小的數(shù)字，背后涉及應(yīng)用和數(shù)據(jù)庫日志的實(shí)時(shí)計(jì)算、存儲和展示等全鏈路所有環(huán)節(jié)，是真正的跨團(tuán)隊(duì)技術(shù)攻關(guān)。

[[248750]]

 

最終不負(fù)眾望，我們雙 11 零點(diǎn) GMV 第一個(gè)數(shù)字跳動是在 3 秒，嚴(yán)格控制在 5 秒內(nèi)，是非常非常不容易的!

不僅如此，為了保證整個(gè)大屏展示萬無一失，我們做了雙鏈路冗余，類似于飛機(jī)雙發(fā)動機(jī)，兩條鏈路同時(shí)計(jì)算，并可實(shí)時(shí)切換。

我想大家一定不了解大屏上一個(gè)小小的數(shù)字，背后還有如此多的故事和技術(shù)挑戰(zhàn)吧。雙 11 就是如此，由無數(shù)小的環(huán)節(jié)組成，背后凝聚了每個(gè)阿里人的付出。

2016 年：吃自己的狗糧

做過大規(guī)模系統(tǒng)的人都知道，監(jiān)控系統(tǒng)就如同我們的眼睛一樣，如果沒有它，系統(tǒng)發(fā)生什么狀況我們都不知道。

我們數(shù)據(jù)庫也有一套監(jiān)控系統(tǒng)，通過部署在主機(jī)上的 Agent，定期采集主機(jī)和數(shù)據(jù)庫的關(guān)鍵指標(biāo)，包括：CPU 和 IO 利用率，數(shù)據(jù)庫 QPS、TPS 和響應(yīng)時(shí)間，慢 SQL 日志等等。

并把這些指標(biāo)存儲在數(shù)據(jù)庫中，進(jìn)行分析和展示，最初這個(gè)數(shù)據(jù)庫也是 MySQL。

隨著阿里巴巴數(shù)據(jù)庫規(guī)模越來越大，整個(gè)監(jiān)控系統(tǒng)就成為了瓶頸，比如：采集精度，受限于系統(tǒng)能力，最初我們只能做到 1 分鐘，后來經(jīng)過歷年的優(yōu)化，我們把采集精度提升到 10 秒。

但是，最讓人感到尷尬的是：每一年雙 11 零點(diǎn)前，我們通常都有一個(gè)預(yù)案，對監(jiān)控系統(tǒng)進(jìn)行降級操作，比如降低采集精度，關(guān)閉某些監(jiān)控項(xiàng)等等。這是因?yàn)楦叻迤诘膲毫μ螅坏靡讯鵀橹?/p>

另外一個(gè)業(yè)務(wù)挑戰(zhàn)來自安全部，他們對我們提出一個(gè)要求，希望能夠采集到每一條在數(shù)據(jù)庫上運(yùn)行的 SQL，并能實(shí)時(shí)送到大數(shù)據(jù)計(jì)算平臺進(jìn)行分析。

這個(gè)要求對我們更是不可能完成的任務(wù)，因?yàn)槊恳粋€(gè)時(shí)刻運(yùn)行的 SQL 是非常巨大的，通常的做法只能做到采樣，現(xiàn)在要求是一條不漏的記錄下來，并且能夠進(jìn)行分析，挑戰(zhàn)非常大。

2016 年雙 11，我們啟動了一個(gè)項(xiàng)目：對我們整個(gè)監(jiān)控系統(tǒng)進(jìn)行了重新設(shè)計(jì)。

目標(biāo)：具備秒級監(jiān)控能力和全量 SQL 的采集計(jì)算能力，且雙 11 峰值不降級。

第一是要解決海量監(jiān)控?cái)?shù)據(jù)的存儲和計(jì)算問題，我們選擇了阿里巴巴自研的時(shí)序數(shù)據(jù)庫 TSDB，它是專門針對 IOT 和 APM 等場景下的海量時(shí)序數(shù)據(jù)而設(shè)計(jì)的數(shù)據(jù)庫。

第二是要解決全量 SQL 的采集和計(jì)算的問題，我們在 AliSQL 內(nèi)置了一個(gè)實(shí)時(shí) SQL 采集接口，SQL 執(zhí)行后不需要寫日志就直接通過消息隊(duì)列傳輸?shù)搅饔?jì)算平臺上進(jìn)行實(shí)時(shí)處理，實(shí)現(xiàn)了全量 SQL 的分析與處理。

解決了這兩個(gè)技術(shù)難題后，2016 年雙 11，我們達(dá)到了秒級監(jiān)控和全量 SQL 采集的業(yè)務(wù)目標(biāo)。

后來，這些監(jiān)控?cái)?shù)據(jù)和全量 SQL 成為了一個(gè)巨大的待挖掘的寶庫，通過對這些數(shù)據(jù)的分析，并與 AI 技術(shù)相結(jié)合，我們推出了 CloudDBA 數(shù)據(jù)庫智能化診斷引擎。

我們相信數(shù)據(jù)庫的未來是 Self-driving Database，它有四個(gè)特性：自診斷、自優(yōu)化、自決策和自恢復(fù)。如前文所述，目前我們在智能化方向上已經(jīng)取得了一些進(jìn)展。

現(xiàn)在，TSDB 已經(jīng)是阿里云上的一個(gè)產(chǎn)品，而 CloudDBA 除了服務(wù)阿里巴巴內(nèi)部數(shù)萬工程師，也已經(jīng)在云上為用戶提供數(shù)據(jù)庫優(yōu)化服務(wù)。

我們不僅吃自己的狗糧，解決自己的問題，同時(shí)也用阿里巴巴的場景不斷磨練技術(shù)，服務(wù)更多的云上用戶。這就是雙 11 對技術(shù)的推動作用。

2016-2017：數(shù)據(jù)庫和緩存那點(diǎn)兒事

在雙 11 的歷史上，阿里巴巴自研緩存-Tair 是非常重要的技術(shù)產(chǎn)品，數(shù)據(jù)庫正是因?yàn)橛辛?Tair 的幫助，才扛起了雙 11 如此巨大的數(shù)據(jù)訪問量。

在大規(guī)模使用 Tair 的同時(shí)，開發(fā)同學(xué)也希望數(shù)據(jù)庫可以提供高性能的 KV 接口，并且通過 KV 和 SQL 兩個(gè)接口查詢的數(shù)據(jù)是一致的，這樣可以大大簡化業(yè)務(wù)開發(fā)的工作量，X-KV 因此因用而生。

它是 X-DB 的 KV 組件，通過繞過 SQL 解析的過程，直接訪問內(nèi)存中的數(shù)據(jù)，可以實(shí)現(xiàn)非常高的性能以及比 SQL 接口低數(shù)倍的響應(yīng)時(shí)間。

X-KV 技術(shù)在 2016 年雙 11 第一次得到了應(yīng)用，用戶反饋非常好，QPS 可以做到數(shù)十萬級別。

在 2017 年雙 11，我們又做了一個(gè)黑科技，通過中間件 TDDL 自動來實(shí)現(xiàn) SQL 和 KV 的轉(zhuǎn)換。

開發(fā)不再需要同時(shí)開發(fā)兩套接口，只需要用 SQL 訪問數(shù)據(jù)庫，TDDL 會自動在后臺把 SQL 轉(zhuǎn)換為 KV 接口，進(jìn)一步提升了開發(fā)的效率，降低了數(shù)據(jù)庫的負(fù)載。

 

2016 年雙 11，Tair 碰到了一個(gè)業(yè)界技術(shù)難題：熱點(diǎn)。大家都知道緩存系統(tǒng)中一個(gè) Key 永遠(yuǎn)只能分布在一臺機(jī)器上。

但是雙 11 時(shí)，熱點(diǎn)非常集中，加上訪問量非常大，很容易就超出了單機(jī)的容量限制，CPU 和網(wǎng)卡都會成為瓶頸。

由于熱點(diǎn)無法預(yù)測，可能是流量熱點(diǎn)，也可能是頻率熱點(diǎn)，造成 2016 年雙 11 我們就像消防隊(duì)員一樣四處滅火，疲于奔命。

2017 年，Tair 團(tuán)隊(duì)的同學(xué)就在思考如何解決這個(gè)業(yè)界的技術(shù)難題，并且創(chuàng)新性地提出了一種自適應(yīng)熱點(diǎn)的技術(shù)方案：

• 智能識別技術(shù)， Tair 內(nèi)部采用多級 LRU 的數(shù)據(jù)結(jié)構(gòu)，通過將訪問數(shù)據(jù) Key 的頻率和大小設(shè)定不同權(quán)值，從而放到不同層級的 LRU 上。

這樣淘汰時(shí)可以確保權(quán)值高的那批 Key 得到保留，最終保留下來且超過閾值設(shè)定的就會判斷為熱點(diǎn) Key。

• 動態(tài)散列技術(shù)，當(dāng)發(fā)現(xiàn)熱點(diǎn)后，應(yīng)用服務(wù)器和 Tair 服務(wù)端就會聯(lián)動起來，根據(jù)預(yù)先設(shè)定好的訪問模型，將熱點(diǎn)數(shù)據(jù)動態(tài)散列到 Tair 服務(wù)端其他數(shù)據(jù)節(jié)點(diǎn)的 Hot Zone 存儲區(qū)域去訪問。

 

熱點(diǎn)散列技術(shù)在 2017 年雙 11 中取得了非常顯著的效果，通過將熱點(diǎn)散列到整個(gè)集群，所有集群的水位均降低到了安全線下。

如果沒有這個(gè)能力，那么 2017 年雙 11 很多 Tair 集群都可能出現(xiàn)問題。

可以看出，數(shù)據(jù)庫和緩存是一對互相依賴的好伙伴，他們互相借鑒，取長補(bǔ)短，共同撐起了雙11海量數(shù)據(jù)存儲和訪問的一片天。

2016-2017 年：如絲般順滑的交易曲線是如何做到的

自從有了全鏈路壓測這項(xiàng)技術(shù)后，我們希望每一年雙 11 零點(diǎn)的交易曲線都能如絲般順滑，但是事情往往不像預(yù)期的那樣順利。

2016 年雙 11 零點(diǎn)后，交易曲線出現(xiàn)了一些波動，才逐步攀升到最高點(diǎn)。

事后復(fù)盤時(shí)，我們發(fā)現(xiàn)主要的問題是購物車等數(shù)據(jù)庫在零點(diǎn)的一剎那，由于 Buffer pool 中的數(shù)據(jù)是“冷”的。

當(dāng)大量請求在零點(diǎn)一瞬間到來時(shí)，數(shù)據(jù)庫需要先“熱”起來，需要把數(shù)據(jù)從 SSD 讀取到 Buffer pool 中，這就導(dǎo)致瞬間大量請求的響應(yīng)時(shí)間變長，影響了用戶的體驗(yàn)。

知道了問題原因后，2017 年我們提出了“預(yù)熱”技術(shù)，即在雙 11 前，讓各個(gè)系統(tǒng)充分“熱”起來，包括 Tair，數(shù)據(jù)庫，應(yīng)用等等。

為此專門研發(fā)了一套預(yù)熱系統(tǒng)，預(yù)熱分為數(shù)據(jù)預(yù)熱和應(yīng)用預(yù)熱兩大部分，數(shù)據(jù)預(yù)熱包括：數(shù)據(jù)庫和緩存預(yù)熱，預(yù)熱系統(tǒng)會模擬應(yīng)用的訪問，通過這種訪問將數(shù)據(jù)加載到緩存和數(shù)據(jù)庫中，保證緩存和數(shù)據(jù)庫 BP 的命中率。

應(yīng)用預(yù)熱包括：預(yù)建連接和 JIT 預(yù)熱，我們會在雙 11 零點(diǎn)前預(yù)先建立好數(shù)據(jù)庫連接，防止在高峰時(shí)建立連接的開銷。

同時(shí)，因?yàn)闃I(yè)務(wù)非常復(fù)雜，而 Java 代碼是解釋執(zhí)行的，如果在高峰時(shí)同時(shí)做 JIT 編譯，會消耗大量的 CPU，系統(tǒng)響應(yīng)時(shí)間會拉長，通過 JIT 預(yù)熱，保證代碼可以提前充分編譯。

2017 年雙 11，因?yàn)橄到y(tǒng)有了充分的預(yù)熱，交易曲線在零點(diǎn)時(shí)劃出了一道完美的曲線。

2017-2018 年：存儲計(jì)算分離的技術(shù)突破

2017 年初，集團(tuán)高年級技術(shù)同學(xué)們發(fā)起了一個(gè)技術(shù)討論：到底要不要做存儲計(jì)算分離?由此引發(fā)了一場擴(kuò)日持久的大討論。

包括我在王博士的班上課時(shí)，針對這個(gè)問題也進(jìn)行了一次技術(shù)辯論，由于兩方觀點(diǎn)勢均力敵，最終誰也沒有說服誰。

對于數(shù)據(jù)庫來說，存儲計(jì)算分離更加是一個(gè)非常敏感的技術(shù)話題，大家都知道在 IOE 時(shí)代，小型機(jī)和存儲之間通過 SAN 網(wǎng)絡(luò)連接，本質(zhì)上就是屬于存儲計(jì)算分離架構(gòu)。

現(xiàn)在我們又要回到這個(gè)架構(gòu)上，是不是技術(shù)的倒退?另外，對于數(shù)據(jù)庫來說，IO 的響應(yīng)延時(shí)直接影響了數(shù)據(jù)庫的性能，如何解決網(wǎng)絡(luò)延時(shí)的問題?各種各樣的問題一直困擾著我們，沒有任何結(jié)論。

當(dāng)時(shí)，數(shù)據(jù)庫已經(jīng)可以使用云 ECS 資源來進(jìn)行大促彈性擴(kuò)容，并且已經(jīng)實(shí)現(xiàn)了容器化部署。

但是，我們無論如何也無法回避的一個(gè)問題就是：如果計(jì)算和存儲綁定在一起，就無法實(shí)現(xiàn)極致的彈性，因?yàn)橛?jì)算節(jié)點(diǎn)的遷移必須“搬遷”數(shù)據(jù)。

而且，我們研究了計(jì)算和存儲的能力的增長曲線，我們發(fā)現(xiàn)在雙 11 高峰時(shí)，對于計(jì)算能力的要求陡增。

但是對于存儲能力的要求并沒有發(fā)生顯著變化，如果可以實(shí)現(xiàn)存儲計(jì)算分離，雙 11 高峰我們只需要擴(kuò)容計(jì)算節(jié)點(diǎn)就可以了。

綜上所述，存儲計(jì)算分離是華山一條路，必須搞定。

2017 年中，為了驗(yàn)證可行性，我們選擇在開源分布式存儲 Ceph 的基礎(chǔ)上進(jìn)行優(yōu)化，與此同時(shí)，阿里巴巴自研高性能分布式存儲盤古 2.0 也在緊鑼密鼓的開發(fā)中。

另外一方面，數(shù)據(jù)庫內(nèi)核團(tuán)隊(duì)也參與其中，通過數(shù)據(jù)庫內(nèi)核優(yōu)化減少網(wǎng)絡(luò)延遲對數(shù)據(jù)庫性能的影響。

經(jīng)過大家的共同努力，最終基于盤古 2.0 的計(jì)算存儲分離方案都在 2017 年雙 11 落地，并且驗(yàn)證了使用離線機(jī)頭掛載共享存儲的彈性方案。經(jīng)過這次雙 11，我們證明了數(shù)據(jù)庫存儲計(jì)算分離是完全可行的。

存儲計(jì)算分離的成功離不開一位幕后英雄：高性能和低延遲網(wǎng)絡(luò)，2017 年雙 11 我們使用了 25G 的 TCP 網(wǎng)絡(luò)。

為了進(jìn)一步降低延遲，2018 年雙 11 我們大規(guī)模使用了 RDMA 技術(shù)，大幅度降低了網(wǎng)絡(luò)延遲，這么大規(guī)模的 RDMA 應(yīng)用在整個(gè)業(yè)界都是獨(dú)一無二的。

為了降低 IO 延遲，我們在文件系統(tǒng)這個(gè)環(huán)節(jié)也做了一個(gè)大殺器-DBFS，通過用戶態(tài)技術(shù)，旁路 Kernel，實(shí)現(xiàn) I/O 路徑的 Zero copy。

通過這些技術(shù)的應(yīng)用，達(dá)到了接近于本地存儲的延時(shí)和吞吐。

 

2018 年雙 11，隨著存儲計(jì)算分離技術(shù)的大規(guī)模使用，標(biāo)志著數(shù)據(jù)庫進(jìn)入了一個(gè)新的時(shí)代。

總結(jié)

在 2012 年到 2018 年的這六年，我見證了零點(diǎn)交易數(shù)字的一次次提升，見證了背后數(shù)據(jù)庫技術(shù)的一次次突破，更見證了阿里人那種永不言敗的精神，每一次化“不可能”為“可能”的過程都是阿里技術(shù)人對技術(shù)的不懈追求。

感恩十年雙 11，期待下一個(gè)十年更美好。