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

 

 

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

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

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

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

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

十年使命：推動(dòng)中國(guó)數(shù)據(jù)庫(kù)技術(shù)變革

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

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

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

 

 

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

2005 年-2009 年：商業(yè)數(shù)據(jù)庫(kù)時(shí)代。

2010 年-2015 年：開(kāi)源數(shù)據(jù)庫(kù)時(shí)代。

2016 年-至今：自研數(shù)據(jù)庫(kù)時(shí)代。

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

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

 

 

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

解決了擴(kuò)展性的問(wèn)題，讓數(shù)據(jù)庫(kù)具備了橫向擴(kuò)展(彈性)的能力，為未來(lái)很多年雙11零點(diǎn)交易峰值打下了很好的基礎(chǔ)。

自主可控，我們?cè)?AliSQL 中加入了大量的特性，比如：庫(kù)存熱點(diǎn)補(bǔ)丁，SQL 限流保護(hù)，線程池等等，很多特性都是來(lái)源于雙 11 對(duì)于數(shù)據(jù)庫(kù)的技術(shù)要求，這在商業(yè)數(shù)據(jù)庫(kù)時(shí)代是完全不可能的。

穩(wěn)定性，原來(lái)在商業(yè)數(shù)據(jù)庫(kù)時(shí)代，就如同把所有的雞蛋放在一個(gè)籃子里(小型機(jī))，去 IOE 之后不僅僅解決了單機(jī)故障，更是通過(guò)異地多活的架構(gòu)升級(jí)讓數(shù)據(jù)庫(kù)跨出了城市的限制，可以實(shí)現(xiàn)數(shù)據(jù)庫(kù)城市間的多活和容災(zāi)，大大提升了系統(tǒng)的可用性。

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

我們需要一個(gè)能夠全球部署的原生分布式數(shù)據(jù)庫(kù)，類似于 Google Spanner。

雙 11 的場(chǎng)景對(duì)數(shù)據(jù)庫(kù)提出了極高的要求：在雙 11 零點(diǎn)需要數(shù)據(jù)庫(kù)提供非常高的讀寫能力。

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

我們經(jīng)過(guò)認(rèn)真評(píng)估后發(fā)現(xiàn)，如果繼續(xù)在開(kāi)源數(shù)據(jù)庫(kù)基礎(chǔ)上進(jìn)行改進(jìn)已經(jīng)無(wú)法滿足業(yè)務(wù)需求。

新的硬件技術(shù)的出現(xiàn)，如果說(shuō) SSD 的大規(guī)模使用和 X86 服務(wù)器性能的極大提升推動(dòng)了去 IOE 的進(jìn)程，那么NVM非易失內(nèi)存，F(xiàn)PGA 異構(gòu)計(jì)算，RDMA 高速網(wǎng)絡(luò)等技術(shù)將第二次推動(dòng)數(shù)據(jù)庫(kù)技術(shù)的變革。

 

 

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

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

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

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

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

 

 

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

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

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

 

 

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

2012 年：我的第一次雙 11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是，經(jīng)過(guò)所有人的努力，這件事竟然在雙 11 前兩周取得了突破性進(jìn)展，當(dāng)?shù)谝淮稳�鏈路壓測(cè)成功的時(shí)候，所有人都覺(jué)得不敢相信。

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

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

即便出現(xiàn)了如此多的問(wèn)題，大家依然堅(jiān)定地往前走，我覺(jué)得這就是阿里巴巴與眾不同的地方，因?yàn)槲覀兿嘈潘�以看�?jiàn)。

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

 

 

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

2015 年：大屏背后的故事

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

 

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

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

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

2016 年：吃自己的狗糧

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)時(shí)，數(shù)據(jù)庫(kù)已經(jīng)可以使用云 ECS 資源來(lái)進(jìn)行大促?gòu)椥詳U(kuò)容，并且已經(jīng)實(shí)現(xiàn)了容器化部署。

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

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

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

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

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

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

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

存儲(chǔ)計(jì)算分離的成功離不開(kāi)一位幕后英雄：高性能和低延遲網(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ú)一無(wú)二的。

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

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

 

 

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

總結(jié)

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

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

標(biāo)簽： b2b Google idc Mysql ssd 安全 大數(shù)據(jù) 代碼 服務(wù)器 服務(wù)器性能 公有云 互聯(lián)網(wǎng) 互聯(lián)網(wǎng)技術(shù) 開(kāi)發(fā)者 媒體 全網(wǎng)推廣 數(shù)據(jù)庫(kù) 推廣 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。