阿里技術分享：深度揭祕阿里數據庫技術方案的10年變遷史
本文原題「阿里數據庫十年變遷，那些你不知道的二三事」，來自阿里巴巴官方技術公號的分享。php
一、引言
第十個雙11即未來臨之際，阿里技術推出《十年牧碼記》系列，邀請參與歷年雙11備戰的核心技術大牛，一塊兒回顧阿里技術的變遷。html
今天，阿里數據庫事業部研究員張瑞，將爲你講述雙11數據庫技術鮮爲人知的故事。在零點交易數字一次次提高的背後，既是數據庫技術的一次次突破，也見證了阿里技術人永不言敗的精神，每一次化「不可能」爲「可能」的過程都是阿里技術人對技術的不懈追求。程序員
（本文同步發佈於：http://www.52im.net/thread-2050-1-1.html）算法
二、分享者
張瑞：阿里集團數據庫技術團隊負責人，阿里巴巴研究員，Oracle ACE。雙十一數據庫技術總負責人，曾兩次擔任雙十一技術保障總負責人。自2005年加入阿里巴巴以來，一直主導整個阿里數據庫技術的不斷革新。數據庫
三、阿里數據庫技術發展回顧
再過幾天，咱們即將迎來第十個雙11。過去十年，阿里巴巴技術體系的角色發生了轉變，從雙11推進技術的發展，變成了技術創造新商業。不少技術經過雲計算開始對外輸出，變成了普惠的技術，服務於各個行業，真正作到了推進社會生產力的發展。小程序
這十年，阿里巴巴數據庫團隊一直有一個使命：推進中國數據庫技術變革。從商業數據庫到開源數據庫再到自研數據庫，咱們一直在爲這個使命而努力奮鬥。微信小程序
若是將阿里數據庫發展歷史分爲三個階段的話，分別是：緩存
第一階段（2005-2009）商業數據庫時代；安全
第二階段（2010-2015）開源數據庫時代；性能優化
第三階段（2016年-至今）自研數據庫時代。
商業數據庫時代就是你們所熟知的IOE時代，後來發生了一件大事就是「去IOE」：經過分佈式數據庫中間件TDDL、開源數據庫AliSQL（阿里巴巴的MySQL分支）、高性能X86服務器和SSD，並經過DBA和業務開發同窗的共同努力，成功地替換了商業數據庫Oracle、IBM小型機和EMC高端存儲，今後進入了開源數據庫時代。
去IOE帶來了三個重大的意義：
第一：是解決了擴展性的問題，讓數據庫具有了橫向擴展（彈性）的能力，爲將來不少年雙11零點交易峯值打下了很好的基礎。
第二：是自主可控，咱們在AliSQL中加入了大量的特性，好比：庫存熱點補丁，SQL限流保護，線程池等等，不少特性都是來源於雙11對於數據庫的技術要求，這在商業數據庫時代是徹底不可能的。
第三：是穩定性，原來在商業數據庫時代，就如同把全部的雞蛋放在一個籃子裏（小型機），去IOE以後不只僅解決了單機故障，更是經過異地多活的架構升級讓數據庫跨出了城市的限制，能夠實現數據庫城市間的多活和容災，大大提高了系統的可用性。
小知識：什麼是「去IOE」？
「去IOE」它是阿里巴巴造出的概念。其本意是，在阿里巴巴的IT架構中，去掉IBM的小型機、Oracle數據庫、EMC存儲設備，代之以本身在開源軟件基礎上開發的系統。
自2013年棱鏡門事件以後，我國政府已經意識到政府數據安全的重要性，也增強了政府數據安全方面的工做，有報道稱，思科、IBM、谷歌、高通、英特爾、蘋果、甲骨文、微軟並稱爲美國的「八大金剛」，他們一方面與美國政府、軍隊保持着緊密的聯繫；另外一方面在中國長驅直入，佔據衆多關鍵領域，致使美國情報部門經過這些設備、軟件、網絡獲取信息，給中國的信息安全帶來巨大威脅。「去IOE」與設備採購國產化、自主研發等口號掛鉤，帶有必定的政治色彩。
2008年阿里提出去IOE時很多人以爲是癡人說夢，但通過多年運營阿里雲已經完全完成了去IOE工做，即阿里雲的硬件投入完全拋棄了這三家傳統企業，經歷幾回雙十一的挑戰以後該技術也趨於成熟，有媒體猜想這或許是12306選擇阿里雲的重要緣由。
進入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的工做很是長，大概從五、6月份就開始準備了，最重要的工做就是識別風險，並準確評估出每一個數據庫的壓力。
咱們須要把入口的流量轉換爲每一個業務系統的壓力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-drvingdatabase，它有四個特性：自診斷、自優化、自決策和自恢復。如前文所述，目前咱們在智能化方向上已經取得了一些進展。
如今，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年的這六年，我見證了零點交易數字的一次次提高，見證了背後數據庫技術的一次次突破，更見證了阿里人那種永不言敗的精神，每一次化「不可能」爲「可能」的過程都是阿里技術人對技術的不懈追求。
感恩十年雙11，期待下一個十年更美好。
附錄1：大型架構方面的技術文章
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
>> 更多同類文章 ……
附錄2：大廠技術分享
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(音視頻技術篇)》
《騰訊技術分享：Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符致使的炸羣、APP崩潰的？》
《騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信團隊披露：微信界面卡死超級bug「15。。。。」的前因後果》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《微信客戶端團隊負責人技術訪談：如何着手客戶端性能監控和優化》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬鏈接、支撐微信8億用戶的後臺框架基石 [源碼下載]》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信後臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信後臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量用戶背後的後臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬鏈接背後的後臺解決方案》
《架構之道：3個程序員成就微信朋友圈日均10億發佈量[有視頻]》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《移動端IM實踐：Android版微信如何大幅提高交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提高交互性能（二）》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《信鴿團隊原創：一塊兒走過 iOS10 上消息推送(APNS)的坑》
《騰訊TEG團隊原創：基於MySQL的分佈式數據庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《瞭解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅做技術研究學習)》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2050-1-1.html）
- 1. 深度揭祕騰訊雲數據庫技術7年變遷史
- 2. 阿里技術面分享
- 3. 2017雙11技術揭祕—阿里巴巴數據庫技術架構演進
- 4. Amazon Redshift數據遷移阿里雲MaxCompute技術方案
- 5. 星辰大海：阿里數據體驗技術揭祕！
- 6. 阿里數據庫關鍵技術
- 7. 阿里雲年會人機大戰-技術大揭祕
- 8. 2017阿里技術年度精選集
- 9. 2017阿里技術年度精選（全）
- 10. 阿里資深技術專家的 10 年感悟
- 更多相關文章...
- • XML 相關技術 - XML 教程
- • Hibernate的快照技術 - Hibernate教程
- • 使用阿里雲OSS+CDN部署前端頁面與加速靜態資源
- • 三篇文章瞭解 TiDB 技術內幕 —— 談調度
-
每一个你不满意的现在，都有一个你没有努力的曾经。