虎嗅注：首先，這不是一個軟文，強調這一點對我們來說很重要，儘管寫作者是阿里內部人士。
恰因為他內部人士的身份給了我們完全不一樣的視角和內幕。這正是媒體所無法真正觸及的地方。想了解他們是怎麼應對“雙11”突然湧入的海量訪問量、訂單量、支付筆數等等問題，這篇文章或能解惑。每一個技術背後都經歷了什麼，本文提供了一手的資料。
本文作者張瑞，系阿里集團資料庫技術團隊負責人，雙十一資料庫技術總負責人，曾兩次擔任雙十一技術保障總負責人。
本文由機器之心經授權轉載自虎嗅APP，未經授權禁止二次轉載。
我們即將迎來第十個“雙11”。
過去十年，阿里巴巴技術體系的角色發生了轉變，從“雙11”推動技術的發展，變成了技術創造新商業。很多技術透過雲端計算開始對外輸出，變成了普惠的技術，服務於各個行業，真正做到了推動社會生產力的發展。
這十年，阿里巴巴資料庫團隊一直有一個使命：推動中國資料庫技術變革。從商業資料庫到開源資料庫再到自研資料庫，我們一直在為這個使命而努力奮鬥。
如果將阿里資料庫發展歷史分為三個階段的話，分別是：第一階段（2005~2009）商業資料庫時代、第二階段（2010~2015）開源資料庫時代、第三階段（2016年至今）自研資料庫時代。
商業資料庫時代就是大家所熟知的IOE時代，後來發生了一件大事就是“去IOE”：透過分散式資料庫中介軟體TDDL、開源資料庫AliSQL（阿里巴巴的MySQL分支）、高效能X86伺服器和SSD，並透過DBA和業務開發同學的共同努力，成功地替換了商業資料庫Oracle、IBM小型機和EMC高階儲存，從此進入了開源資料庫時代。
去IOE帶來了三個重大的意義：
第一是解決了擴充套件性的問題，讓資料庫具備了橫向擴充套件（彈性）的能力，為未來很多年雙11零點交易峰值打下了很好的基礎；
第二是自主可控，我們在AliSQL中加入了大量的特性，比如：庫存熱點補丁，SQL限流保護，執行緒池等等，很多特性都是來源於雙11對於資料庫的技術要求，這在商業資料庫時代是完全不可能的；
第三是穩定性，原來在商業資料庫時代，就如同把所有的雞蛋放在一個籃子裡（小型機），去IOE之後不僅僅解決了單機故障，更是透過異地多活的架構升級讓資料庫跨出了城市的限制，可以實現資料庫城市間的多活和容災，大大提升了系統的可用性。
進入2016年，我們開始自研資料庫，代號X-DB。大家一定會問：為什麼要自研資料庫？有以下幾個原因：
第一，我們需要一個能夠全球部署的原生分散式資料庫，類似於Google Spanner；
第二是雙11的場景對資料庫提出了極高的要求，第一是效能，在雙11零點需要資料庫提供非常高的讀寫能力；第二是儲存成本，資料庫使用SSD來儲存資料，而資料存在明顯的冷熱特性，大量冷的歷史資料和熱的線上資料存放在一起，日積月累，佔用了大量寶貴的儲存空間，儲存成本的壓力越來越大。我們經過認真評估後發現，如果繼續在開源資料庫基礎上進行改進已經無法滿足業務需求；
第三是新的硬體技術的出現，如果說SSD的大規模使用和X86伺服器效能的極大提升推動了去IOE的程式，那麼NVM非易失記憶體，FPGA異構計算，RDMA高速網路等技術將第二次推動資料庫技術的變革。
伴隨著每一年的雙11備戰工作，機器資源的準備都是非常重要的一個環節。如何降低雙11的機器資源成本一直是阿里技術人不斷挑戰自我的一個難題。第一個解決方案就是使用雲資源，資料庫從2016年初開始就嘗試使用高效能ECS來解決雙11的機器資源問題。透過這幾年的雙11的不斷磨練，2018年雙11，我們可以直接使用了公有云ECS，並透過VPC網路與阿里巴巴集團內部環境組成混合雲，實現了雙11的彈性大促。
第二個方案就是線上離線混部，日常讓離線任務跑在線上（應用和資料庫）的伺服器上，雙11大促線上應用使用離線的計算資源，要實現這種彈效能力，資料庫最核心要解決一個技術問題就是：儲存計算分離。儲存計算分離後，資料庫可以在雙11使用離線的計算資源，從而實現極致的彈效能力。透過使用雲資源和混部技術，可以最大程度降低雙11交易峰值帶來的成本。
雙11備戰中另外一個重要的技術趨勢就是：智慧化。資料庫和智慧化相結合也是我們一直在探索的一個方向，比如Self-driving Database等。2017年，我們第一次使用智慧化的技術對SQL進行自動最佳化，2018年，我們計劃全網推廣SQL自動最佳化和空間自動最佳化，希望可以使用這些技術降低DBA的工作負擔，提升開發人員效率，並有效提升穩定性。相信未來，在雙11的備戰工作中，會有越來越多的工作可以交給機器來完成。
我從2012年開始參加雙11的備戰工作，多次作為資料庫的隊長和技術保障部總隊長，在這麼多年的備戰工作中，我也經歷了很多有意思的故事，在這裡分享一些給大家。
2012年：我的第一次雙11
2012年是我的第一次雙11，在此之前，我在B2B的資料庫團隊。2012年初，整個集團的基礎設施團隊都合併到了技術保障部，由振飛帶領。
我之前從來沒有參加過雙11，第一年參加雙11后羿（資料庫團隊的負責人）就把隊長的職責給了我，壓力可想而知。那時候備戰雙11的工作非常長，大概從五六月份就開始準備了，最重要的工作就是識別風險，並準確評估出每個資料庫的壓力。
我們需要把入口的流量轉換為每個業務系統的壓力QPS，然後我們根據業務系統的QPS轉換為資料庫的QPS，2012年還沒有全鏈路壓測的技術，只能靠每個業務系統的線下測試，以及每個專業線隊長一次又一次的開會review來發現潛在的風險。
可想而知，這裡面存在巨大的不確定性，每個人都不想自己負責的業務成為短板，而機器資源往往是有限的。這時，就完全靠隊長的經驗了，所以，每個隊長所承擔的壓力都非常巨大。我記得當年雙11的大隊長是李津，據說他當時的壓力大到無法入睡，只能在晚上開車去龍井山頂，開啟車窗才能小憩一會。
而我，由於是第一年參加雙11，經驗為零，完全處於焦慮到死的狀態，幸好當年有一群很靠譜的兄弟和我在一起，他們剛剛經歷了去IOE的洗禮，並且長期與業務開發浸淫在一起，對業務架構和資料庫效能如數家珍，瞭如指掌。透過他們的幫助，我基本摸清了交易整套系統的架構，這對我未來的工作幫助非常大。
經過幾個月緊張的準備，雙11那天終於到來了，我們做好了最充分的準備，但是一切都是那麼地不確定，我們懷著忐忑不安的心情，當零點到來的時候，最壞的情況還是發生了：庫存資料庫的壓力完全超過了容量，同時IC（商品）資料庫的網路卡也被打滿了。我記得很清楚，當時我們看著資料庫的上的監控指標，束手無策。這裡有一個小細節：由於我們根本沒有估算到這麼大的壓力，當時監控螢幕上資料庫的壓力指標顯示超過了100%。
正在這時，技術總指揮李津大喊一聲：“大家都別慌！”
這時我們才抬頭看到交易的數字不斷衝上新高，心裡才稍微平靜下來。事實上，對於IC資料庫網路卡被打滿，庫存資料庫超過容量，都超出了我們的預期，所以最終我們什麼預案也沒做，就這樣度過了零點的高峰。
因為這些原因，2012年的的雙11產生了大量的超賣，給公司帶來了很大的損失。那一年的雙11後，庫存、商品、退款和相應資料庫的同學，為了處理超賣導致的問題，沒日沒夜加了兩週的班。而且，我周圍很多朋友，都在抱怨高峰時的使用者體驗實在太糟糕了。我們下決心要在第二年的雙11解決這些問題。
2013年：庫存熱點最佳化和不起眼的影子表
2012年的雙11結束後，我們就開始著手解決庫存資料庫的效能提升。庫存扣減場景是一個典型的熱點問題，即多個使用者去爭搶扣減同一個商品的庫存（對資料庫來說，一個商品的庫存就是資料庫內的一行記錄），資料庫內對同一行的更新由行鎖來控制併發。我們發現當單執行緒（排隊）去更新一行記錄時，效能非常高，但是當非常多的執行緒去併發更新一行記錄時，整個資料庫的效能會跌到慘不忍睹，趨近於零。
當時資料庫核心團隊做了兩個不同的技術實現：一個是排隊方案，另一個併發控制方案。兩者各有優劣，解決的思路都是要把無序的爭搶變為有序的排隊，從而提升熱點庫存扣減的效能問題。兩個技術方案透過不斷的完善和PK，最終都做到了成熟穩定，滿足業務的效能要求，最終為了萬無一失，我們把兩個方案都整合到了AliSQL（阿里巴巴的MySQL分支）中，並且可以透過開關控制。最終，我們透過一整年的努力，在2013年的雙11解決了庫存熱點的問題，這是第一次庫存的效能提升。在這之後的2016年雙11，我們又做了一次重大的最佳化，把庫存扣減效能在2013年的基礎上又提升了十倍，稱為第二次庫存效能最佳化。
2013年堪稱雙11歷史上里程碑式的一年，因為這一年出現了一個突破性的技術：全鏈路壓測。我非常佩服第一次提出全鏈路壓測理念的人：李津，他當時問我們：有沒有可能線上上環境進行全模擬的測試？所有人的回答都是：不可能！當然，我認為這對於資料庫是更加不可能的，最大的擔心是壓測流量產生的資料該如何處理，從來沒聽說過哪家公司敢線上上系統做壓測，萬一資料出現問題，這個後果將會非常嚴重。
我記得在2013年某天一個炎熱的下午，我正在庫存資料庫的問題中焦頭爛額的時候，叔同（全鏈路壓測技術負責人）來找我商量全鏈路壓測資料庫的技術方案。就在那個下午，我們兩個人討論出了一個“影子表”的方案，即線上上系統中建立一套“影子表”來儲存和處理所有的壓測資料，並且由系統保證兩套表結構的同步。
我們對這件事心裡都沒底，我相信在雙11的前幾周，沒有幾個人相信全鏈路壓測能夠落地，我們大部分的準備工作還是按照人工review+線下壓測的方式進行。但是，經過所有人的努力，這件事竟然在雙11前兩週取得了突破性進展，當第一次全鏈路壓測成功的時候，所有人都覺得不敢相信。
最後，雙11的前幾個晚上，幾乎每天晚上都會做一輪全鏈路壓測，每個人都樂此不疲，給我留下的印象實在太深刻了。但這個過程，也並不是一帆風順，我們壓出了很多次故障，多次寫錯了資料，甚至影響了第二天的報表，長時間高壓力的壓測甚至影響了機器和SSD的壽命。即便出現瞭如此多的問題，大家依然堅定地往前走，我覺得這就是阿里巴巴與眾不同的地方，因為我們相信所以看見。事實也證明，全鏈路壓測變成了雙11備戰中最有效的大殺器。
現在全鏈路壓測技術已經不是秘密，它已經成為阿里雲上的一個產品，變成了更加普惠的技術服務更多企業。
2015年：大屏背後的故事
2015年，我從資料庫的隊長成為整個技術保障部的總隊長，負責整個技術設施領域的雙11備戰工作，包括IDC、網路、硬體、資料庫、CDN應用等所有技術領域，我第一次面對如此多的專業技術領域，對我又是一次全新的挑戰。
但是，這一次我卻被一個新問題難倒了：大屏。
2015年，我們第一次舉辦天貓雙11晚會，這一年晚會和媒體中心第一次不在杭州園區，而是選擇在北京水立方，媒體中心全球26小時直播，全球都在關注我們雙11當天的盛況，需要北京杭州兩地協同作戰，困難和挑戰可想而知。
大家都知道對媒體直播大屏來說最最重要的兩個時刻，一個是雙11零點開始的時刻，一個是雙11二十四點結束的時刻，全程要求媒體直播大屏上跳動的GMV數字儘可能的不延遲，那一年我們為了提升北京水立方現場的體驗及和杭州總指揮中心的互動，在零點前有一個倒數計時環節，連線杭州光明頂作戰指揮室，逍遙子會為大家揭幕2015雙11啟動，然後直接切換到我們的媒體大屏，所以對GMV數字的要求基本上是零延遲，這個挑戰有多大不言而喻。
然而，第一次全鏈路壓測時卻非常不盡人意，延時在幾十秒以上，當時的總指揮振飛堅決地說：GMV第一個數字跳動必須要在5秒內，既要求5秒內就拿到實時的交易數字，又要求這個數字必須是準確的，所有人都覺得這是不可能完成的任務。當時，導演組也提了另外一個預案，可以在雙11零點後，先顯示一個數字跳動的特效（不是真實的數字），等我們準備好之後，再切換到真實的交易數字，但對媒體大屏來說所有屏上的資料都必須是真實且正確的（這是阿里人的價值觀），所以我們不可能用這個兜底的方案，所有人想得都是如何把延遲做到5秒內。
當天晚上，所有相關的團隊就成立一個大屏技術攻關組，開始封閉技術攻關，別看一個小小的數字，背後涉及應用和資料庫日誌的實時計算、儲存和展示等全鏈路所有環節，是真正的跨團隊技術攻關，最終不負眾望，我們雙11零點GMV第一個數字跳動是在3秒，嚴格控制在5秒內，是非常非常不容易的！不僅如此，為了保證整個大屏展示萬無一失，我們做了雙鏈路冗餘，類似於飛機雙發動機，兩條鏈路同時計算，並可實時切換。
我想大家一定不瞭解大屏上一個小小的數字，背後還有如此多的故事和技術挑戰吧。雙11就是如此，由無數小的環節組成，背後凝聚了每個阿里人的付出。
2016年：吃自己的狗糧
做過大規模系統的人都知道，監控系統就如同我們的眼睛一樣，如果沒有它，系統發生什麼狀況我們都不知道。我們資料庫也有一套監控系統，透過部署在主機上的agent，定期採集主機和資料庫的關鍵指標，包括：CPU和IO利用率，資料庫QPS、TPS和響應時間，慢SQL日誌等等，並把這些指標儲存在資料庫中，進行分析和展示，最初這個資料庫也是MySQL。
隨著阿里巴巴資料庫規模越來越大，整個監控系統就成為了瓶頸，比如：採集精度，受限於系統能力，最初我們只能做到1分鐘，後來經過歷年的最佳化，我們把採集精度提升到10秒。但是，最讓人感到尷尬的是：每一年雙11零點前，我們通常都有一個預案：對監控系統進行降級操作，比如降低採集精度，關閉某些監控項等等。這是因為高峰期的壓力太大，不得已而為之。
另外一個業務挑戰來自安全部，他們對我們提出一個要求，希望能夠採集到每一條在資料庫上執行的SQL，並能實時送到大資料計算平臺進行分析。這個要求對我們更是不可能完成的任務，因為每一個時刻執行的SQL是非常巨大的，通常的做法只能做到取樣，現在要求是一條不漏的記錄下來，並且能夠進行分析，挑戰非常大。
2016年雙11，我們啟動了一個專案：對我們整個監控系統進行了重新設計。目標：具備秒級監控能力和全量SQL的採集計算能力，且雙11峰值不降級。
第一是要解決海量監控資料的儲存和計算問題，我們選擇了阿里巴巴自研的時序資料庫TSDB，它是專門針對IOT和APM等場景下的海量時序資料而設計的資料庫。第二是要解決全量SQL的採集和計算的問題，我們在AliSQL內建了一個實時SQL採集介面，SQL執行後不需要寫日誌就直接透過訊息佇列傳輸到流計算平臺上進行實時處理，實現了全量SQL的分析與處理。解決了這兩個技術難題後，2016年雙11，我們達到了秒級監控和全量SQL採集的業務目標。
後來，這些監控資料和全量SQL成為了一個巨大的待挖掘的寶庫，透過對這些資料的分析，並與AI技術相結合，我們推出了CloudDBA資料庫智慧化診斷引擎。我們相信資料庫的未來是Self-drving database，它有四個特性：自診斷、自最佳化、自決策和自恢復。如前文所述，目前我們在智慧化方向上已經取得了一些進展。
現在，TSDB已經是阿里雲上的一個產品，而CloudDBA除了服務阿里巴巴內部數萬工程師，也已經在雲上為使用者提供資料庫最佳化服務。我們不僅吃自己的狗糧，解決自己的問題，同時也用阿里巴巴的場景不斷磨練技術，服務更多的雲上使用者。這就是雙11對技術的推動作用。
2016~2017年：資料庫和快取那點兒事
在雙11的歷史上，阿里巴巴自研快取-Tair是非常重要的技術產品，資料庫正是因為有了Tair的幫助，才扛起了雙11如此巨大的資料訪問量。在大規模使用Tair的同時，開發同學也希望資料庫可以提供高效能的KV介面，並且透過KV和SQL兩個介面查詢的資料是一致的，這樣可以大大簡化業務開發的工作量， X-KV因此因用而生，它是X-DB的KV元件，透過繞過SQL解析的過程，直接訪問記憶體中的資料，可以實現非常高的效能以及比SQL介面低數倍的響應時間。X-KV技術在2016年雙11第一次得到了應用，使用者反饋非常好，QPS可以做到數十萬級別。
在2017年雙11，我們又做了一個技術，透過中介軟體TDDL自動來實現SQL和KV的轉換，開發不再需要同時開發兩套介面，只需要用SQL訪問資料庫，TDDL會自動在後臺把SQL自動轉換為KV介面，進一步提升了開發的效率，降低了資料庫的負載。
2016年雙11，Tair碰到了一個業界技術難題：熱點。大家都知道快取系統中一個key永遠只能分佈在一臺機器上，但是雙11時，熱點非常集中，加上訪問量非常大，很容易就超出了單機的容量限制，CPU和網路卡都會成為瓶頸。由於熱點無法預測，可能是流量熱點，也可能是頻率熱點，造成2016年雙11我們就像消防隊員一樣四處滅火，疲於奔命。2017年，Tair團隊的同學就在思考如何解決這個業界的技術難題，並且創新性地提出了一種自適應熱點的技術方案：第一是智慧識別技術， Tair內部採用多級LRU的資料結構，透過將訪問資料Key的頻率和大小設定不同權值，從而放到不同層級的LRU上，這樣淘汰時可以確保權值高的那批Key得到保留。最終保留下來且超過閾值設定的就會判斷為熱點Key。第二是動態雜湊技術，當發現熱點後，應用伺服器和Tair服務端就會聯動起來，根據預先設定好的訪問模型，將熱點資料動態雜湊到Tair服務端其它資料節點的HotZone儲存區域去訪問。
熱點雜湊技術在2017年雙11中取得了非常顯著的效果，透過將熱點雜湊到整個叢集，所有叢集的水位均降低到了安全線下。如果沒有這個能力，那麼2017年雙11很多Tair叢集都可能出現問題。
可以看出，資料庫和快取是一對互相依賴的好夥伴，他們互相借鑑，取長補短，共同撐起了雙11海量資料儲存和訪問的一片天。
2016~2017年：如絲般順滑的交易曲線是如何做到的
自從有了全鏈路壓測這項技術後，阿里巴巴技術保障部負責人周明就提出了一個新的目標：希望每一年雙11零點的交易曲線都能“如絲般順滑”。這個目標對技術提出了非常高的要求。2016年雙11零點後，交易曲線出現了一些波動，才攀逐步升到最高點。事後覆盤時，我們發現主要的問題是購物車等資料庫在零點的一剎那，由於Buffer pool中的資料是“冷”的，當大量請求在零點一瞬間到來時，資料庫需要先“熱”起來，需要把資料從SSD讀取到Buffer pool中，這就導致瞬間大量請求的響應時間變長，影響了使用者的體驗。
知道了問題原因後，2017年我們提出了“預熱””技術，即在雙11前，讓各個系統充分“熱”起來，包括Tair，資料庫，應用等等。為此專門研發了一套預熱系統，預熱分為資料預熱和應用預熱兩大部分，資料預熱包括：資料庫和快取預熱，預熱系統會模擬應用的訪問，透過這種訪問將資料載入到快取和資料庫中，保證快取和資料庫BP的命中率。應用預熱包括：預建連線和JIT預熱，我們會在雙11零點前預先建立好資料庫連線，防止在高峰時建立連線的開銷。同時，因為業務非常複雜，而JAVA程式碼是解釋執行的，如果在高峰時同時做JIT編譯，會消耗了大量的CPU，系統響應時間會拉長，透過JIT預熱，保證程式碼可以提前充分編譯。
2017年雙11，因為系統有了充分的預熱，交易曲線在零點時劃出了一道完美的曲線。
2017～2018年：儲存計算分離的技術突破
2017年初，集團高年級技術同學們發起了一個技術討論：到底要不要做儲存計算分離？由此引發了一場擴日持久的大討論。包括我在王堅博士的班上課時，針對這個問題也進行了一次技術辯論，由於兩方觀點勢均力敵，最終誰也沒有說服誰。
對於資料庫來說，儲存計算分離更加是一個非常敏感的技術話題，大家都知道在IOE時代，小型機和儲存之間透過SAN網路連線，本質上就是屬於儲存計算分離架構。現在我們又要回到這個架構上，是不是技術的倒退？另外，對於資料庫來說，IO的響應延時直接影響了資料庫的效能，如何解決網路延時的問題？各種各樣的問題一直困擾著我們，沒有任何結論。
當時，資料庫已經可以使用雲ECS資源來進行大促彈性擴容，並且已經實現了容器化部署。但是，我們無論如何也無法迴避的一個問題就是：如果計算和儲存繫結在一起，就無法實現極致的彈性，因為計算節點的遷移必須“搬遷”資料。而且，我們研究了計算和儲存的能力的增長曲線，我們發現在雙11高峰時，對於計算能力的要求陡增，但是對於儲存能力的要求並沒有發生顯著變化，如果可以實現儲存計算分離，雙11高峰我們只需要擴容計算節點就可以了。綜上所述，儲存計算分離是華山一條路，必須搞定。
2017年中，為了驗證可行性，我們選擇在開源分散式儲存Ceph的基礎上進行最佳化，與此同時，阿里巴巴自研高效能分散式儲存盤古2.0也在緊鑼密鼓的開發中。另外一方面，資料庫核心團隊也參與其中，透過資料庫核心最佳化減少網路延遲對資料庫效能的影響。經過大家的共同努力，最終基於盤古2.0的計算儲存分離方案都在2017年雙11落地，並且驗證了使用離線機頭掛載共享儲存的彈性方案。經過這次雙11，我們證明了資料庫儲存計算分離是完全可行的。
儲存計算分離的成功離不開一位幕後英雄：高效能和低延遲網路，2017年雙11我們使用了25G的TCP網路，為了進一步降低延遲，2018年雙11我們大規模使用了RDMA技術，大幅度降低了網路延遲，這麼大規模的RDMA應用在整個業界都是獨一無二的。為了降低IO延遲，我們在檔案系統這個環節也做了一個大殺器-DBFS，透過使用者態技術，旁路kernel，實現I/O路徑的Zero copy。透過這些技術的應用，達到了接近於本儲存地的延時和吞吐。
2018年雙11，隨著儲存計算分離技術的大規模使用，標誌著資料庫進入了一個新的時代。
總結
在2012年到2018年的這六年，我見證了零點交易數字的一次次提升，見證了背後資料庫技術的一次次突破，更見證了阿里人那種永不言敗的精神，每一次化“不可能”為“可能”的過程都是阿里技術人對技術的不懈追求。
本文由機器之心經授權轉載自虎嗅APP，未經授權禁止二次轉載。