本文原題“阿里數據庫十年變遷，那些你不知道的二三事”，來自阿里巴巴官方技術公號的分享。
1、引言
第十個雙11即將來臨之際，阿里技術推出《十年牧碼記》系列，邀請參與歷年雙11備戰的核心技術大牛，一起回顧阿里技術的變遷。
今天，阿里數據庫事業部研究員張瑞，將爲你講述雙11數據庫技術不爲人知的故事。在零點交易數字一次次提升的背後，既是數據庫技術的一次次突破，也見證了阿里技術人永不言敗的精神，每一次化“不可能”爲“可能”的過程都是阿里技術人對技術的不懈追求。
（本文同步發佈於：http://www.52im.net/thread-2050-1-1.html）
2、分享者
張瑞：阿里集團數據庫技術團隊負責人，阿里巴巴研究員，Oracle ACE。雙十一數據庫技術總負責人，曾兩次擔任雙十一技術保障總負責人。自2005年加入阿里巴巴以來，一直主導整個阿里數據庫技術的不斷革新。
3、阿里數據庫技術發展回顧
再過幾天，我們即將迎來第十個雙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的備戰工作，多次作爲數據庫的隊長和技術保障部總隊長，在這麼多年的備戰工作中，我也經歷了很多有意思的故事，在這裏分享一些給大家。
4、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解決這些問題。
5、2013年：庫存熱點優化和不起眼的影子表
2012年的雙11結束後，我們就開始着手解決庫存數據庫的性能提升。庫存扣減場景是一個典型的熱點問題，即多個用戶去爭搶扣減同一個商品的庫存（對數據庫來說，一個商品的庫存就是數據庫內的一行記錄），數據庫內對同一行的更新由行鎖來控制併發。我們發現當單線程（排隊）去更新一行記錄時，性能非常高，但是當非常多的線程去併發更新一行記錄時，整個數據庫的性能會跌到慘不忍睹，趨近於零。
當時數據庫內核團隊做了兩個不同的技術實現：一個是排隊方案，另一個併發控制方案。兩者各有優劣，解決的思路都是要把無序的爭搶變爲有序的排隊，從而提升熱點庫存扣減的性能問題。兩個技術方案通過不斷的完善和PK，最終都做到了成熟穩定，滿足業務的性能要求，最終爲了萬無一失，我們把兩個方案都集成到了AliSQL（阿里巴巴的MySQL分支）中，並且可以通過開關控制。最終，我們通過一整年的努力，在2013年的雙11解決了庫存熱點的問題，這是第一次庫存的性能提升。在這之後的2016年雙11，我們又做了一次重大的優化，把庫存扣減性能在2013年的基礎上又提升了十倍，稱爲第二次庫存性能優化。
2013年堪稱雙11歷史上里程碑式的一年，因爲這一年出現了一個突破性的技術-全鏈路壓測。我非常佩服第一次提出全鏈路壓測理念的人-李津，他當時問我們：有沒有可能在線上環境進行全仿真的測試？所有人的回答都是：不可能！當然，我認爲這對於數據庫是更加不可能的，最大的擔心是壓測流量產生的數據該如何處理，從來沒聽說過哪家公司敢在線上系統做壓測，萬一數據出現問題，這個後果將會非常嚴重。
我記得在2013年某天一個炎熱的下午，我正在庫存數據庫的問題中焦頭爛額的時候，叔同(全鏈路壓測技術負責人)來找我商量全鏈路壓測數據庫的技術方案。就在那個下午，我們兩個人討論出了一個“影子表”的方案，即在線上系統中建立一套“影子表”來存儲和處理所有的壓測數據，並且由系統保證兩套表結構的同步。但是，我們對這件事心裏都沒底，我相信在雙11的前幾周，沒有幾個人相信全鏈路壓測能夠落地，我們大部分的準備工作還是按照人工review+線下壓測的方式進行。但是，經過所有人的努力，這件事竟然在雙11前兩週取得了突破性進展，當第一次全鏈路壓測成功的時候，所有人都覺得不敢相信。
最後，雙11的前幾個晚上，幾乎每天晚上都會做一輪全鏈路壓測，每個人都樂此不疲，給我留下的印象實在太深刻了。但這個過程，也並不是一帆風順，我們壓出了很多次故障，多次寫錯了數據，甚至影響了第二天的報表，長時間高壓力的壓測甚至影響了機器和SSD的壽命。即便出現瞭如此多的問題，大家依然堅定地往前走，我覺得這就是阿里巴巴與衆不同的地方，因爲我們相信所以看見。事實也證明，全鏈路壓測變成了雙11備戰中最有效的大殺器。
如今，全鏈路壓測技術已經成爲阿里雲上的一個產品，變成了更加普惠的技術服務更多企業。
6、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就是如此，由無數小的環節組成，背後凝聚了每個阿里人的付出。
7、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對技術的推動作用。
8、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海量數據存儲和訪問的一片天。
9、2016-2017年：如絲般順滑的交易曲線是如何做到的
自從有了全鏈路壓測這項技術後，我們希望每一年雙11零點的交易曲線都能如絲般順滑，但是事情往往不像預期的那樣順利。2016年雙11零點後，交易曲線出現了一些波動，才攀逐步升到最高點。事後覆盤時，我們發現主要的問題是購物車等數據庫在零點的一剎那，由於Buffer pool中的數據是“冷”的，當大量請求在零點一瞬間到來時，數據庫需要先“熱”起來，需要把數據從SSD讀取到Buffer pool中，這就導致瞬間大量請求的響應時間變長，影響了用戶的體驗。
知道了問題原因後，2017年我們提出了“預熱””技術，即在雙11前，讓各個系統充分“熱”起來，包括Tair，數據庫，應用等等。爲此專門研發了一套預熱系統，預熱分爲數據預熱和應用預熱兩大部分，數據預熱包括：數據庫和緩存預熱，預熱系統會模擬應用的訪問，通過這種訪問將數據加載到緩存和數據庫中，保證緩存和數據庫BP的命中率。應用預熱包括：預建連接和JIT預熱，我們會在雙11零點前預先建立好數據庫連接，防止在高峯時建立連接的開銷。同時，因爲業務非常複雜，而JAVA代碼是解釋執行的，如果在高峯時同時做JIT編譯，會消耗了大量的CPU，系統響應時間會拉長，通過JIT預熱，保證代碼可以提前充分編譯。
2017年雙11，因爲系統有了充分的預熱，交易曲線在零點時劃出了一道完美的曲線。
10、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，隨着存儲計算分離技術的大規模使用，標誌着數據庫進入了一個新的時代。
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）