摘要：今天，阿里數(shù)據(jù)庫事業(yè)部研究員張瑞，將為你講述雙數(shù)據(jù)庫技術(shù)不為人知的故事。這十年，阿里巴巴數(shù)據(jù)庫團(tuán)隊(duì)一直有一個(gè)使命推動(dòng)中國數(shù)據(jù)庫技術(shù)變革。

第十個(gè)雙11即將來臨之際，阿里技術(shù)推出《十年牧碼記》系列，邀請(qǐng)參與歷年雙11備戰(zhàn)的核心技術(shù)大牛，一起回顧阿里技術(shù)的變遷。

今天，阿里數(shù)據(jù)庫事業(yè)部研究員張瑞，將為你講述雙11數(shù)據(jù)庫技術(shù)不為人知的故事。在零點(diǎn)交易數(shù)字一次次提升的背后，既是數(shù)據(jù)庫技術(shù)的一次次突破，也見證了阿里技術(shù)人永不言敗的精神，每一次化“不可能”為“可能”的過程都是阿里技術(shù)人對(duì)技術(shù)的不懈追求。

再過幾天，我們即將迎來第十個(gè)雙11。過去十年，阿里巴巴技術(shù)體系的角色發(fā)生了轉(zhuǎn)變，從雙11推動(dòng)技術(shù)的發(fā)展，變成了技術(shù)創(chuàng)造新商業(yè)。很多技術(shù)通過云計(jì)算開始對(duì)外輸出，變成了普惠的技術(shù)，服務(wù)于各個(gè)行業(yè)，真正做到了推動(dòng)社會(huì)生產(chǎn)力的發(fā)展。

這十年，阿里巴巴數(shù)據(jù)庫團(tuán)隊(duì)一直有一個(gè)使命：推動(dòng)中國數(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高端存儲(chǔ)，從此進(jìn)入了開源數(shù)據(jù)庫時(shí)代。

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

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

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

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

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

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

第二是雙11的場(chǎng)景對(duì)數(shù)據(jù)庫提出了極高的要求：

性能：在雙11零點(diǎn)需要數(shù)據(jù)庫提供非常高的讀寫能力；

存儲(chǔ)成本：數(shù)據(jù)庫使用SSD來存儲(chǔ)數(shù)據(jù)，而數(shù)據(jù)存在明顯的冷熱特性，大量冷的歷史數(shù)據(jù)和熱的在線數(shù)據(jù)存放在一起，日積月累，占用了大量寶貴的存儲(chǔ)空間，存儲(chǔ)成本的壓力越來越大。我們經(jīng)過認(rèn)真評(píng)估后發(fā)現(xiàn)，如果繼續(xù)在開源數(shù)據(jù)庫基礎(chǔ)上進(jìn)行改進(jìn)已經(jīng)無法滿足業(yè)務(wù)需求。

第三是新的硬件技術(shù)的出現(xiàn)，如果說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ù)庫技術(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ù)問題就是：存儲(chǔ)計(jì)算分離。存儲(chǔ)計(jì)算分離后，數(shù)據(jù)庫可以在雙11使用離線的計(jì)算資源，從而實(shí)現(xiàn)極致的彈性能力。通過使用云資源和混部技術(shù)，可以最大程度降低雙11交易峰值帶來的成本。

雙11備戰(zhàn)中另外一個(gè)重要的技術(shù)趨勢(shì)就是：智能化。數(shù)據(jù)庫和智能化相結(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)，提升開發(fā)人員效率，并有效提升穩(wěn)定性。相信未來，在雙11的備戰(zhàn)工作中，會(huì)有越來越多的工作可以交給機(jī)器來完成。

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

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)備了，最重要的工作就是識(shí)別風(fēng)險(xiǎn)，并準(zhǔn)確評(píng)估出每個(gè)數(shù)據(jù)庫的壓力。

我們需要把入口的流量轉(zhuǎn)換為每個(gè)業(yè)務(wù)系統(tǒng)的壓力QPS，然后我們根據(jù)業(yè)務(wù)系統(tǒng)的QPS轉(zhuǎn)換為數(shù)據(jù)庫的QPS，2012年還沒有全鏈路壓測(cè)的技術(shù)，只能靠每個(gè)業(yè)務(wù)系統(tǒng)的線下測(cè)試，以及每個(gè)專業(yè)線隊(duì)長一次又一次的開會(huì)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í)的壓力大到無法入睡，只能在晚上開車去龍井山頂，打開車窗才能小憩一會(huì)。

而我，由于是第一年參加雙11，經(jīng)驗(yàn)為零，完全處于焦慮到死的狀態(tài)，幸好當(dāng)年有一群很靠譜兄弟和我在一起，他們剛剛經(jīng)歷了去IOE的洗禮，并且長期與業(yè)務(wù)開發(fā)浸淫在一起，對(duì)業(yè)務(wù)架構(gòu)和數(shù)據(jù)庫性能如數(shù)家珍，了若指掌。通過他們的幫助，我基本摸清了交易整套系統(tǒng)的架構(gòu)，這對(duì)我未來的工作幫助非常大。

經(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í)上，對(duì)于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解決這些問題。

2012年的雙11結(jié)束后，我們就開始著手解決庫存數(shù)據(jù)庫的性能提升。庫存扣減場(chǎng)景是一個(gè)典型的熱點(diǎn)問題，即多個(gè)用戶去爭(zhēng)搶扣減同一個(gè)商品的庫存（對(duì)數(shù)據(jù)庫來說，一個(gè)商品的庫存就是數(shù)據(jù)庫內(nèi)的一行記錄），數(shù)據(jù)庫內(nèi)對(duì)同一行的更新由行鎖來控制并發(fā)。我們發(fā)現(xiàn)當(dāng)單線程（排隊(duì)）去更新一行記錄時(shí)，性能非常高，但是當(dāng)非常多的線程去并發(fā)更新一行記錄時(shí)，整個(gè)數(shù)據(jù)庫的性能會(huì)跌到慘不忍睹，趨近于零。

當(dāng)時(shí)數(shù)據(jù)庫內(nèi)核團(tuán)隊(duì)做了兩個(gè)不同的技術(shù)實(shí)現(xiàn)：一個(gè)是排隊(duì)方案，另一個(gè)并發(fā)控制方案。兩者各有優(yōu)劣，解決的思路都是要把無序的爭(zhēng)搶變?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ù)-全鏈路壓測(cè)。我非常佩服第一次提出全鏈路壓測(cè)理念的人-李津，他當(dāng)時(shí)問我們：有沒有可能在線上環(huán)境進(jìn)行全仿真的測(cè)試？所有人的回答都是：不可能！當(dāng)然，我認(rèn)為這對(duì)于數(shù)據(jù)庫是更加不可能的，最大的擔(dān)心是壓測(cè)流量產(chǎn)生的數(shù)據(jù)該如何處理，從來沒聽說過哪家公司敢在線上系統(tǒng)做壓測(cè)，萬一數(shù)據(jù)出現(xiàn)問題，這個(gè)后果將會(huì)非常嚴(yán)重。

我記得在2013年某天一個(gè)炎熱的下午，我正在庫存數(shù)據(jù)庫的問題中焦頭爛額的時(shí)候，叔同(全鏈路壓測(cè)技術(shù)負(fù)責(zé)人)來找我商量全鏈路壓測(cè)數(shù)據(jù)庫的技術(shù)方案。就在那個(gè)下午，我們兩個(gè)人討論出了一個(gè)“影子表”的方案，即在線上系統(tǒng)中建立一套“影子表”來存儲(chǔ)和處理所有的壓測(cè)數(shù)據(jù)，并且由系統(tǒng)保證兩套表結(jié)構(gòu)的同步。但是，我們對(duì)這件事心里都沒底，我相信在雙11的前幾周，沒有幾個(gè)人相信全鏈路壓測(cè)能夠落地，我們大部分的準(zhǔn)備工作還是按照人工review+線下壓測(cè)的方式進(jìn)行。但是，經(jīng)過所有人的努力，這件事竟然在雙11前兩周取得了突破性進(jìn)展，當(dāng)?shù)谝淮稳溌穳簻y(cè)成功的時(shí)候，所有人都覺得不敢相信。

最后，雙11的前幾個(gè)晚上，幾乎每天晚上都會(huì)做一輪全鏈路壓測(cè)，每個(gè)人都樂此不疲，給我留下的印象實(shí)在太深刻了。但這個(gè)過程，也并不是一帆風(fēng)順，我們壓出了很多次故障，多次寫錯(cuò)了數(shù)據(jù)，甚至影響了第二天的報(bào)表，長時(shí)間高壓力的壓測(cè)甚至影響了機(jī)器和SSD的壽命。即便出現(xiàn)了如此多的問題，大家依然堅(jiān)定地往前走，我覺得這就是阿里巴巴與眾不同的地方，因?yàn)槲覀兿嘈潘钥匆?。事?shí)也證明，全鏈路壓測(cè)變成了雙11備戰(zhàn)中最有效的大殺器。

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

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

2015年，我們第一次舉辦天貓雙11晚會(huì)，這一年晚會(huì)和媒體中心第一次不在杭州園區(qū)，而是選擇在北京水立方，媒體中心全球26小時(shí)直播，全球都在關(guān)注我們雙11當(dāng)天的盛況，需要北京杭州兩地協(xié)同作戰(zhàn)，困難和挑戰(zhàn)可想而知！大家都知道對(duì)媒體直播大屏來說最最重要的兩個(gè)時(shí)刻，一個(gè)是雙11零點(diǎn)開始的時(shí)刻，一個(gè)是雙11二十四點(diǎn)結(jié)束的時(shí)刻，全程要求媒體直播大屏上跳動(dòng)的GMV數(shù)字盡可能的不延遲，那一年我們?yōu)榱颂嵘本┧⒎浆F(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)決的說：GMV第一個(gè)數(shù)字跳動(dòng)必須要在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ù)字跳動(dòng)的特效（不是真實(shí)的數(shù)字），等我們準(zhǔn)備好之后，再切換到真實(shí)的交易數(shù)字，但對(duì)媒體大屏來說所有屏上的數(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ì)算、存儲(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è)大屏展示萬無一失，我們做了雙鏈路冗余，類似于飛機(jī)雙發(fā)動(dòng)機(jī)，兩條鏈路同時(shí)計(jì)算，并可實(shí)時(shí)切換。

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

做過大規(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)存儲(chǔ)在數(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ù)案：對(duì)監(jiān)控系統(tǒng)進(jìn)行降級(jí)操作，比如降低采集精度，關(guān)閉某些監(jiān)控項(xiàng)等等。這是因?yàn)楦叻迤诘膲毫μ螅坏靡讯鵀橹?/p>

另外一個(gè)業(yè)務(wù)挑戰(zhàn)來自安全部，他們對(duì)我們提出一個(gè)要求，希望能夠采集到每一條在數(shù)據(jù)庫上運(yùn)行的SQL，并能實(shí)時(shí)送到大數(shù)據(jù)計(jì)算平臺(tái)進(jìn)行分析。這個(gè)要求對(duì)我們更是不可能完成的任務(wù)，因?yàn)槊恳粋€(gè)時(shí)刻運(yùn)行的SQL是非常巨大的，通常的做法只能做到采樣，現(xiàn)在要求是一條不漏的記錄下來，并且能夠進(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ì)算問題，我們選擇了阿里巴巴自研的時(shí)序數(shù)據(jù)庫TSDB，它是專門針對(duì)IOT和APM等場(chǎng)景下的海量時(shí)序數(shù)據(jù)而設(shè)計(jì)的數(shù)據(jù)庫。第二是要解決全量SQL的采集和計(jì)算的問題，我們?cè)贏liSQL內(nèi)置了一個(gè)實(shí)時(shí)SQL采集接口，SQL執(zhí)行后不需要寫日志就直接通過消息隊(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)。

后來，這些監(jiān)控?cái)?shù)據(jù)和全量SQL成為了一個(gè)巨大的待挖掘的寶庫，通過對(duì)這些數(shù)據(jù)的分析，并與AI技術(shù)相結(jié)合，我們推出了CloudDBA數(shù)據(jù)庫智能化診斷引擎。我們相信數(shù)據(jù)庫的未來是Self-drvingdatabase，它有四個(gè)特性：自診斷、自優(yōu)化、自決策和自恢復(fù)。如前文所述，目前我們?cè)谥悄芑较蛏弦呀?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í)也用阿里巴巴的場(chǎng)景不斷磨練技術(shù)，服務(wù)更多的云上用戶。這就是雙11對(duì)技術(shù)的推動(dòng)作用。

在雙11的歷史上，阿里巴巴自研緩存-Tair是非常重要的技術(shù)產(chǎn)品，數(shù)據(jù)庫正是因?yàn)橛辛薚air的幫助，才扛起了雙11如此巨大的數(shù)據(jù)訪問量。在大規(guī)模使用Tair的同時(shí)，開發(fā)同學(xué)也希望數(shù)據(jù)庫可以提供高性能的KV接口，并且通過KV和SQL兩個(gè)接口查詢的數(shù)據(jù)是一致的，這樣可以大大簡(jiǎn)化業(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ù)十萬級(jí)別。在2017年雙11，我們又做了一個(gè)黑科技，通過中間件TDDL自動(dòng)來實(shí)現(xiàn)SQL和KV的轉(zhuǎn)換，開發(fā)不再需要同時(shí)開發(fā)兩套接口，只需要用SQL訪問數(shù)據(jù)庫，TDDL會(huì)自動(dòng)在后臺(tái)把SQL自動(dòng)轉(zhuǎn)換為KV接口，進(jìn)一步提升了開發(fā)的效率，降低了數(shù)據(jù)庫的負(fù)載。

2016年雙11，Tair碰到了一個(gè)業(yè)界技術(shù)難題：熱點(diǎn)。大家都知道緩存系統(tǒng)中一個(gè)key永遠(yuǎn)只能分布在一臺(tái)機(jī)器上，但是雙11時(shí)，熱點(diǎn)非常集中，加上訪問量非常大，很容易就超出了單機(jī)的容量限制，CPU和網(wǎng)卡都會(huì)成為瓶頸。由于熱點(diǎn)無法預(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)，通過將訪問數(shù)據(jù)Key的頻率和大小設(shè)定不同權(quán)值，從而放到不同層級(jí)的LRU上，這樣淘汰時(shí)可以確保權(quán)值高的那批Key得到保留。最終保留下來且超過閾值設(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)起來，根據(jù)預(yù)先設(shè)定好的訪問模型，將熱點(diǎn)數(shù)據(jù)動(dòng)態(tài)散列到Tair服務(wù)端其它數(shù)據(jù)節(jié)點(diǎn)的HotZone存儲(chǔ)區(qū)域去訪問。

熱點(diǎn)散列技術(shù)在2017年雙11中取得了非常顯著的效果，通過將熱點(diǎn)散列到整個(gè)集群，所有集群的水位均降低到了安全線下。如果沒有這個(gè)能力，那么2017年雙11很多Tair集群都可能出現(xiàn)問題。

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

自從有了全鏈路壓測(cè)這項(xiàng)技術(shù)后，我們希望每一年雙11零點(diǎn)的交易曲線都能如絲般順滑，但是事情往往不像預(yù)期的那樣順利。2016年雙11零點(diǎn)后，交易曲線出現(xiàn)了一些波動(dòng)，才攀逐步升到最高點(diǎn)。事后復(fù)盤時(shí)，我們發(fā)現(xiàn)主要的問題是購物車等數(shù)據(jù)庫在零點(diǎn)的一剎那，由于Buffer pool中的數(shù)據(jù)是“冷”的，當(dāng)大量請(qǐng)求在零點(diǎn)一瞬間到來時(shí)，數(shù)據(jù)庫需要先“熱”起來，需要把數(shù)據(jù)從SSD讀取到Buffer pool中，這就導(dǎo)致瞬間大量請(qǐng)求的響應(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)會(huì)模擬應(yīng)用的訪問，通過這種訪問將數(shù)據(jù)加載到緩存和數(shù)據(jù)庫中，保證緩存和數(shù)據(jù)庫BP的命中率。應(yīng)用預(yù)熱包括：預(yù)建連接和JIT預(yù)熱，我們會(huì)在雙11零點(diǎn)前預(yù)先建立好數(shù)據(jù)庫連接，防止在高峰時(shí)建立連接的開銷。同時(shí)，因?yàn)闃I(yè)務(wù)非常復(fù)雜，而JAVA代碼是解釋執(zhí)行的，如果在高峰時(shí)同時(shí)做JIT編譯，會(huì)消耗了大量的CPU，系統(tǒng)響應(yīng)時(shí)間會(huì)拉長，通過JIT預(yù)熱，保證代碼可以提前充分編譯。

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

2017年初，集團(tuán)高年級(jí)技術(shù)同學(xué)們發(fā)起了一個(gè)技術(shù)討論：到底要不要做存儲(chǔ)計(jì)算分離？由此引發(fā)了一場(chǎng)擴(kuò)日持久的大討論。包括我在王博士的班上課時(shí)，針對(duì)這個(gè)問題也進(jìn)行了一次技術(shù)辯論，由于兩方觀點(diǎn)勢(shì)均力敵，最終誰也沒有說服誰。對(duì)于數(shù)據(jù)庫來說，存儲(chǔ)計(jì)算分離更加是一個(gè)非常敏感的技術(shù)話題，大家都知道在IOE時(shí)代，小型機(jī)和存儲(chǔ)之間通過SAN網(wǎng)絡(luò)連接，本質(zhì)上就是屬于存儲(chǔ)計(jì)算分離架構(gòu)。現(xiàn)在我們又要回到這個(gè)架構(gòu)上，是不是技術(shù)的倒退？另外，對(duì)于數(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ì)算和存儲(chǔ)綁定在一起，就無法實(shí)現(xiàn)極致的彈性，因?yàn)橛?jì)算節(jié)點(diǎn)的遷移必須“搬遷”數(shù)據(jù)。而且，我們研究了計(jì)算和存儲(chǔ)的能力的增長曲線，我們發(fā)現(xiàn)在雙11高峰時(shí)，對(duì)于計(jì)算能力的要求陡增，但是對(duì)于存儲(chǔ)能力的要求并沒有發(fā)生顯著變化，如果可以實(shí)現(xiàn)存儲(chǔ)計(jì)算分離，雙11高峰我們只需要擴(kuò)容計(jì)算節(jié)點(diǎn)就可以了。綜上所述，存儲(chǔ)計(jì)算分離是華山一條路，必須搞定。

2017年中，為了驗(yàn)證可行性，我們選擇在開源分布式存儲(chǔ)Ceph的基礎(chǔ)上進(jìn)行優(yōu)化，與此同時(shí)，阿里巴巴自研高性能分布式存儲(chǔ)盤古2.0也在緊鑼密鼓的開發(fā)中。另外一方面，數(shù)據(jù)庫內(nèi)核團(tuán)隊(duì)也參與其中，通過數(shù)據(jù)庫內(nèi)核優(yōu)化減少網(wǎng)絡(luò)延遲對(duì)數(shù)據(jù)庫性能的影響。經(jīng)過大家的共同努力，最終基于盤古2.0的計(jì)算存儲(chǔ)分離方案都在2017年雙11落地，并且驗(yàn)證了使用離線機(jī)頭掛載共享存儲(chǔ)的彈性方案。經(jīng)過這次雙11，我們證明了數(shù)據(jù)庫存儲(chǔ)計(jì)算分離是完全可行的。

存儲(chǔ)計(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延遲，我們?cè)谖募到y(tǒng)這個(gè)環(huán)節(jié)也做了一個(gè)大殺器-DBFS，通過用戶態(tài)技術(shù)，旁路kernel，實(shí)現(xiàn)I/O路徑的Zero copy。通過這些技術(shù)的應(yīng)用，達(dá)到了接近于本存儲(chǔ)地的延時(shí)和吞吐。

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

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

云服務(wù)器99元拼團(tuán)購！拉新還可贏現(xiàn)金紅包！300萬等你瓜分！
馬上一鍵開團(tuán)贏紅包： http://click.aliyun.com/m/100...

本文作者：張瑞

閱讀原文

本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”，如需轉(zhuǎn)載請(qǐng)聯(lián)系原作者。