摘要：今天，阿里數據庫事業部研究員張瑞，將為你講述雙數據庫技術不為人知的故事。這十年，阿里巴巴數據庫團隊一直有一個使命推動中國數據庫技術變革。

第十個雙11即將來臨之際，阿里技術推出《十年牧碼記》系列，邀請參與歷年雙11備戰的核心技術大牛，一起回顧阿里技術的變遷。

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

再過幾天，我們即將迎來第十個雙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，在此之前，我在B2B的數據庫團隊，2012年初，整個集團的基礎設施團隊都合并到了技術保障部，由振飛帶領。我之前從來沒有參加過雙11，第一年參加雙11后羿（數據庫團隊的負責人）就把隊長的職責給了我，壓力可想而知。那時候備戰雙11的工作非常長，大概從5、6月份就開始準備了，最重要的工作就是識別風險，并準確評估出每個數據庫的壓力。

我們需要把入口的流量轉換為每個業務系統的壓力QPS，然后我們根據業務系統的QPS轉換為數據庫的QPS，2012年還沒有全鏈路壓測的技術，只能靠每個業務系統的線下測試，以及每個專業線隊長一次又一次的開會review來發現潛在的風險。

可想而知，這里面存在巨大的不確定性，每個人都不想自己負責的業務成為短板，而機器資源往往是有限的，這時，就完全靠隊長的經驗了，所以，每個隊長所承擔的壓力都非常巨大。我記得當年雙11的大隊長是李津，據說他當時的壓力大到無法入睡，只能在晚上開車去龍井山頂，打開車窗才能小憩一會。

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

經過幾個月緊張的準備，雙11那天終于到來了，我們做好了最充分的準備，但是一切都是那么地不確定，我們懷著忐忑不安的心情，當零點到來的時候，最壞的情況還是發生了：庫存數據庫的壓力完全超過了容量，同時IC（商品）數據庫的網卡也被打滿了。我記得很清楚，當時我們看著數據庫的上的監控指標，束手無策。這里有一個小細節：由于我們根本沒有估算到這么大的壓力，當時監控屏幕上數據庫的壓力指標顯示超過了100%。

正在這時，技術總指揮李津大喊一聲：“大家都別慌！”這時我們才抬頭看到交易的數字不斷沖上新高，心里才稍微平靜下來。事實上，對于IC數據庫網卡被打滿，庫存數據庫超過容量，都超出了我們的預期，所以最終我們什么預案也沒做，就這樣度過了零點的高峰。

因為這些原因，2012年的的雙11產生了大量的超賣，給公司帶來了很大的損失。那一年的雙11后，庫存、商品、退款和相應數據庫的同學，為了處理超賣導致的問題，沒日沒夜加了兩周的班。而且，我周圍很多朋友，都在抱怨高峰時的用戶體驗實在太糟糕了。我們下決心要在第二年的雙11解決這些問題。

2012年的雙11結束后，我們就開始著手解決庫存數據庫的性能提升。庫存扣減場景是一個典型的熱點問題，即多個用戶去爭搶扣減同一個商品的庫存（對數據庫來說，一個商品的庫存就是數據庫內的一行記錄），數據庫內對同一行的更新由行鎖來控制并發。我們發現當單線程（排隊）去更新一行記錄時，性能非常高，但是當非常多的線程去并發更新一行記錄時，整個數據庫的性能會跌到慘不忍睹，趨近于零。

當時數據庫內核團隊做了兩個不同的技術實現：一個是排隊方案，另一個并發控制方案。兩者各有優劣，解決的思路都是要把無序的爭搶變為有序的排隊，從而提升熱點庫存扣減的性能問題。兩個技術方案通過不斷的完善和PK，最終都做到了成熟穩定，滿足業務的性能要求，最終為了萬無一失，我們把兩個方案都集成到了AliSQL（阿里巴巴的MySQL分支）中，并且可以通過開關控制。最終，我們通過一整年的努力，在2013年的雙11解決了庫存熱點的問題，這是第一次庫存的性能提升。在這之后的2016年雙11，我們又做了一次重大的優化，把庫存扣減性能在2013年的基礎上又提升了十倍，稱為第二次庫存性能優化。

2013年堪稱雙11歷史上里程碑式的一年，因為這一年出現了一個突破性的技術-全鏈路壓測。我非常佩服第一次提出全鏈路壓測理念的人-李津，他當時問我們：有沒有可能在線上環境進行全仿真的測試？所有人的回答都是：不可能！當然，我認為這對于數據庫是更加不可能的，最大的擔心是壓測流量產生的數據該如何處理，從來沒聽說過哪家公司敢在線上系統做壓測，萬一數據出現問題，這個后果將會非常嚴重。

我記得在2013年某天一個炎熱的下午，我正在庫存數據庫的問題中焦頭爛額的時候，叔同(全鏈路壓測技術負責人)來找我商量全鏈路壓測數據庫的技術方案。就在那個下午，我們兩個人討論出了一個“影子表”的方案，即在線上系統中建立一套“影子表”來存儲和處理所有的壓測數據，并且由系統保證兩套表結構的同步。但是，我們對這件事心里都沒底，我相信在雙11的前幾周，沒有幾個人相信全鏈路壓測能夠落地，我們大部分的準備工作還是按照人工review+線下壓測的方式進行。但是，經過所有人的努力，這件事竟然在雙11前兩周取得了突破性進展，當第一次全鏈路壓測成功的時候，所有人都覺得不敢相信。

最后，雙11的前幾個晚上，幾乎每天晚上都會做一輪全鏈路壓測，每個人都樂此不疲，給我留下的印象實在太深刻了。但這個過程，也并不是一帆風順，我們壓出了很多次故障，多次寫錯了數據，甚至影響了第二天的報表，長時間高壓力的壓測甚至影響了機器和SSD的壽命。即便出現了如此多的問題，大家依然堅定地往前走，我覺得這就是阿里巴巴與眾不同的地方，因為我們相信所以看見。事實也證明，全鏈路壓測變成了雙11備戰中最有效的大殺器。

如今，全鏈路壓測技術已經成為阿里云上的一個產品，變成了更加普惠的技術服務更多企業。

2015年，我從數據庫的隊長成為整個技術保障部的總隊長，負責整個技術設施領域的雙11備戰工作，包括IDC、網絡、硬件、數據庫、CDN，應用等所有技術領域，我第一次面對如此多的專業技術領域，對我又是一次全新的挑戰。但是，這一次我卻被一個新問題難倒了：大屏。

2015年，我們第一次舉辦天貓雙11晚會，這一年晚會和媒體中心第一次不在杭州園區，而是選擇在北京水立方，媒體中心全球26小時直播，全球都在關注我們雙11當天的盛況，需要北京杭州兩地協同作戰，困難和挑戰可想而知！大家都知道對媒體直播大屏來說最最重要的兩個時刻，一個是雙11零點開始的時刻，一個是雙11二十四點結束的時刻，全程要求媒體直播大屏上跳動的GMV數字盡可能的不延遲，那一年我們為了提升北京水立方現場的體驗及和杭州總指揮中心的互動，在零點前有一個倒計時環節，連線杭州光明頂作戰指揮室，逍遙子會為大家揭幕2015雙11啟動，然后直接切換到我們的媒體大屏，所以對GMV數字的要求基本上是零延遲，這個挑戰有多大不言而喻！然而，第一次全鏈路壓測時卻非常不盡人意，延時在幾十秒以上，當時的總指揮振飛堅決的說：GMV第一個數字跳動必須要在5秒內，既要求5秒內就拿到實時的交易數字，又要求這個數字必須是準確的，所有人都覺得這是不可能完成的任務。當時，導演組也提了另外一個預案，可以在雙11零點后，先顯示一個數字跳動的特效（不是真實的數字），等我們準備好之后，再切換到真實的交易數字，但對媒體大屏來說所有屏上的數據都必須是真實且正確的（這是阿里人的價值觀），所以我們不可能用這個兜底的方案，所有人想的都是如何把延遲做到5秒內，當天晚上，所有相關的團隊就成立一個大屏技術攻關組，開始封閉技術攻關，別看一個小小的數字，背后涉及應用和數據庫日志的實時計算、存儲和展示等全鏈路所有環節，是真正的跨團隊技術攻關，最終不負眾望，我們雙11零點GMV第一個數字跳動是在3秒，嚴格控制在5秒內，是非常非常不容易的！不僅如此，為了保證整個大屏展示萬無一失，我們做了雙鏈路冗余，類似于飛機雙發動機，兩條鏈路同時計算，并可實時切換。

我想大家一定不了解大屏上一個小小的數字，背后還有如此多的故事和技術挑戰吧。雙11就是如此，由無數小的環節組成，背后凝聚了每個阿里人的付出。

做過大規模系統的人都知道，監控系統就如同我們的眼睛一樣，如果沒有它，系統發生什么狀況我們都不知道。我們數據庫也有一套監控系統，通過部署在主機上的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-drvingdatabase，它有四個特性：自診斷、自優化、自決策和自恢復。如前文所述，目前我們在智能化方向上已經取得了一些進展。

現在，TSDB已經是阿里云上的一個產品，而CloudDBA除了服務阿里巴巴內部數萬工程師，也已經在云上為用戶提供數據庫優化服務。我們不僅吃自己的狗糧，解決自己的問題，同時也用阿里巴巴的場景不斷磨練技術，服務更多的云上用戶。這就是雙11對技術的推動作用。

在雙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海量數據存儲和訪問的一片天。

自從有了全鏈路壓測這項技術后，我們希望每一年雙11零點的交易曲線都能如絲般順滑，但是事情往往不像預期的那樣順利。2016年雙11零點后，交易曲線出現了一些波動，才攀逐步升到最高點。事后復盤時，我們發現主要的問題是購物車等數據庫在零點的一剎那，由于Buffer pool中的數據是“冷”的，當大量請求在零點一瞬間到來時，數據庫需要先“熱”起來，需要把數據從SSD讀取到Buffer pool中，這就導致瞬間大量請求的響應時間變長，影響了用戶的體驗。

知道了問題原因后，2017年我們提出了“預熱””技術，即在雙11前，讓各個系統充分“熱”起來，包括Tair，數據庫，應用等等。為此專門研發了一套預熱系統，預熱分為數據預熱和應用預熱兩大部分，數據預熱包括：數據庫和緩存預熱，預熱系統會模擬應用的訪問，通過這種訪問將數據加載到緩存和數據庫中，保證緩存和數據庫BP的命中率。應用預熱包括：預建連接和JIT預熱，我們會在雙11零點前預先建立好數據庫連接，防止在高峰時建立連接的開銷。同時，因為業務非常復雜，而JAVA代碼是解釋執行的，如果在高峰時同時做JIT編譯，會消耗了大量的CPU，系統響應時間會拉長，通過JIT預熱，保證代碼可以提前充分編譯。

2017年雙11，因為系統有了充分的預熱，交易曲線在零點時劃出了一道完美的曲線。

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年的這六年，我見證了零點交易數字的一次次提升，見證了背后數據庫技術的一次次突破，更見證了阿里人那種永不言敗的精神，每一次化“不可能”為“可能”的過程都是阿里技術人對技術的不懈追求。

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

本文作者：張瑞

閱讀原文

本文來自云棲社區合作伙伴“阿里技術”，如需轉載請聯系原作者。