摘要： 12月13-14日，由云棲社區(qū)與阿里巴巴技術協(xié)會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背后的黑科技。本文是《雙11萬億流量下的分布式緩存》演講整理，本文主要從Tair發(fā)展和應用開始談起，接著談及雙11面臨的挑戰(zhàn)，重點分享了性能優(yōu)化方面的實踐，最后對緩存難題給出了解決方案。

12月13-14日，由云棲社區(qū)與阿里巴巴技術協(xié)會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背后的黑科技。本文是《雙11萬億流量下的分布式緩存》演講整理，本文主要從Tair發(fā)展和應用開始談起，接著談及雙11面臨的挑戰(zhàn)，重點分享了性能優(yōu)化方面的實踐，最后對緩存難題給出了解決方案。內容如下。

分享嘉賓：

宗岱：阿里巴巴資深技術專家，2008年加入淘寶，阿里分布式緩存、NoSQL數據庫Tair和Tengine負責人。

Tair概覽

Tair發(fā)展歷程

Tair在阿里巴巴被廣泛使用，無論是淘寶天貓瀏覽下單，還是打開優(yōu)酷瀏覽播放時，背后都有Tair的身影默默支撐巨大的流量。Tair的發(fā)展歷程如下：

2010.04 Tair v1.0正式推出@淘寶核心系統(tǒng)；
2012.06 Tair v2.0推出LDB持久化產品，滿足持久化存儲需求；
2012.10 推出RDB緩存產品，引入類Redis接口，滿足復雜數據結構的存儲需求；
2013.03 在LDB的基礎上針對全量導入場景上線Fastdump產品，大幅度降低導入時間和訪問延時；
2014.07 Tair v3.0 正式上線，性能X倍提升；
2016.11 泰斗智能運維平臺上線，助力2016雙11邁入千億時代；
2017.11 性能飛躍，熱點散列，資源調度，支持萬億流量。

Tair是一個高性能、分布式、可擴展、高可靠的key/value結構存儲系統(tǒng)！Tair特性主要體現(xiàn)在以下幾個方面：

高性能：在高吞吐下保證低延遲，是阿里集團內調用量最大系統(tǒng)之一，雙11達到每秒5億次峰值的調用量，平均訪問延遲在1毫秒以下；
高可用：自動failover 單元化機房內以及機房間容災，確保系統(tǒng)在任何情況下都能正常運行；
規(guī)?；?#xff1a;分布全球各個數據中心，阿里集團各個BU都在使用；
業(yè)務覆蓋：電商、螞蟻、合一、阿里媽媽、高德、阿里健康等。

Tair除了普通Key/Value系統(tǒng)提供的功能，比如get、put、delete以及批量接口外，還有一些附加的實用功能，使得其有更廣的適用場景。Tair應用場景包括以下四種：

MDB 典型應用場景：用于緩存，降低對后端數據庫的訪問壓力，比如淘寶中的商品都是緩存在Tair中；用于臨時數據存儲，部分數據丟失不會對業(yè)務產生較大影響；讀多寫少，讀qps達到萬級別以上。

LDB 典型應用場景：通用kv存儲、交易快照、安全風控等；存儲黑白單數據，讀qps很高；計數器功能，更新非常頻繁，且數據不可丟失。

RDB 典型應用場景：復雜的數據結構的緩存與存儲，如播放列表，直播間等。

FastDump 典型應用場景：周期性地將離線數據快速地導入到Tair集群中，快速使用到新的數據，對在線讀取要求非常高；讀取低延遲，不能有毛刺。

雙 11 挑戰(zhàn)怎么辦？

2012-2017年數據如圖，可以看到，2012年GMV小于200億，2017年GMV達到1682億，交易創(chuàng)建峰值從1.4萬達到32.5萬，峰值QPS從1300萬達到近5億。我們可以得出，Tair訪問峰值增速：Tair峰值 > 交易峰值 > 總GMV，如何確保成本不超過交易峰值增速？對于帶數據的分布式系統(tǒng)來說，緩存問題都是比較難解決的，緩存流量特別大，2017年雙11后，我們徹底解決掉了緩存問題。我們現(xiàn)在的交易系統(tǒng)和導入系統(tǒng)都是多地域多單元多機房部署的，如何快速部署業(yè)務系統(tǒng)呢？

多地域多單元

多地域多單元首先是中心機房，我們做了雙機房容災，兩側還有若干個單元。機房內系統(tǒng)圖如圖，從流量接入進統(tǒng)一接入層-應用層-中間件-Tair-DB，在數據層我們會做多地域的數據同步。

彈性建站

我們需要系統(tǒng)具備彈性建站的能力。Tair是一個復雜的分布式存儲系統(tǒng)，我們?yōu)橹⒘艘徽走\營管控系統(tǒng)泰斗，在泰斗里建設彈性建站系統(tǒng)，它會經過一系列工作步驟將Tair系統(tǒng)建設起來，我們還會從系統(tǒng)層面、集群層面和實例連通層面進行驗證，以確保系統(tǒng)功能、穩(wěn)定性萬無一失。

Tair的每一個業(yè)務集群水位其實是不一樣的，雙11前的每一次全鏈路壓測下，由于業(yè)務模型的變化，所用Tair資源會發(fā)生變化，造成水位出現(xiàn)變化。在此情況下，我們需要每一次壓測完在多個集群間調度Tair資源，如果水位低，就會把某些機器服務器資源往水位高挪，達到所有集群水位值接近。

數據同步

對于單元化業(yè)務，我們提供了本單元訪問本地Tair的能力，對于有些非單元化業(yè)務，我們也提供了更靈活的訪問模型。同步延遲是我們一直在做的事情，2017年雙11每秒同步數據已經達到了千萬級別，那么，如何更好地解決非單元化業(yè)務在多單元寫入數據沖突問題？這也是我們一直考慮的。

性能優(yōu)化降成本

服務器成本并不是隨著訪問量線性增長，每年以百分之三四十成本在下降，我們主要通過服務器性能優(yōu)化、客戶端性能優(yōu)化和不同的業(yè)務解決方案三方面達到此目的。

內存數據結構

圖為MDB內存數據結構示意圖，我們在進程啟動之后會申請一大塊內存，在內存中將格式組織起來。主要有slab分配器、hashmap和內存池，內存寫滿后會經過LRU鏈進行數據淘汰。隨著服務器CPU核數不斷增加，如果不能很好處理鎖競爭，很難提升整體性能。

參考了各種文獻和操作系統(tǒng)的設計，我們使用了細粒度鎖、無鎖數據結構、CPU本地數據結構和讀拷貝更新（讀鏈表時不需要加鎖）。左圖為未經過優(yōu)化時鎖競爭各個功能模塊消耗圖，可以看到網絡部分和數據查找部分消耗最多，優(yōu)化后（右圖）有80%的處理都是在網絡和數據查找，這是符合我們期望的。

用戶態(tài)協(xié)議棧

鎖優(yōu)化后，我們發(fā)現(xiàn)很多CPU消耗在內核態(tài)上，這時我們采用DPDK+Alisocket來替換掉原有內核態(tài)協(xié)議棧，Alisocket采用DPDK在用戶態(tài)進行網卡收包，并利用自身協(xié)議棧提供socket API，對其進行集成。我們與業(yè)內類似系統(tǒng)進行了對比，如圖。

內存合并

單機性能提升足夠高后，帶來問題是單位qps對應內存量變少了，怎么解決呢？我們發(fā)現(xiàn)公用集群整體看內存還是有的，某些slab沒有辦法寫入， 比如64字節(jié)slab沒有被寫滿，但是72字節(jié)slab全部寫滿了，內存池都被申請完了，我們把64字節(jié)slab空閑頁相互合并，這樣可以釋放大量空閑頁。其中不可避免加入模式鎖，在觸發(fā)合并閾值情況下，切換成加鎖狀態(tài)，合并都是在訪問量低峰期做的，對于業(yè)務峰值來說沒有問題。

客戶端優(yōu)化

客戶端我們做了兩方面優(yōu)化：網絡框架替換，適配協(xié)程，從原有的mina替換成netty，吞吐量提升40%；序列化優(yōu)化，集成 kryo和hessian，吞吐量提升16%+。

內存網格

如何與業(yè)務結合來降低整體Tair與業(yè)務成本？Tair提供了多級存儲一體化解決業(yè)務問題，比如安全風控場景，讀寫量超大、有大量本地計算，我們可以在業(yè)務機器本地存下該業(yè)務機器所要訪問的數據，大量讀會命中在本地，而且寫在一段時間內是可合并的，在一定周期后，合并寫到遠端Tair集群上作為最終存儲。我們提供讀寫穿透，包括合并寫和原有Tair本身具有多單元復制的能力，雙11時業(yè)務對Tair讀取降至27.68%，對Tair寫入降至55.75%。

熱點難題已解決

緩存擊穿

緩存從開始的單點發(fā)展到分布式系統(tǒng)，通過數據分片方式組織，但對每一個數據分片來說，還是作為單點存在的。當有大促活動或熱點新聞時，數據往往是在某一個分片上的，這就會造成單點訪問，進而緩存中某個節(jié)點就會無法承受這么大壓力，致使大量請求沒有辦法響應。即便是限流也是有損操作，可能也會造成全系統(tǒng)崩潰。我們發(fā)現(xiàn)，問題根源是訪問熱點，需要徹底解決該問題。

熱點散列

經過多種方案的探索，采用了熱點散列方案。我們評估過客戶端本地cache方案和二級緩存方案，它們可以在一定程度上解決熱點問題，但各有弊端。而熱點散列直接在數據節(jié)點上加hotzone區(qū)域，讓hotzone承擔熱點數據存儲。對于整個方案來說，最關鍵有以下幾步：

智能識別。熱點數據總是在變化的，或是頻率熱點，或是流量熱點。
實時反饋。采用多級LRU的數據結構，設定不同權值放到不同層級的LRU上，一旦LRU數據寫滿后，會從低級LRU鏈開始淘汰，確保權值高的得到保留。
動態(tài)散列。當訪問到熱點時，Appserver和服務端就會聯(lián)動起來，根據預先設定好的訪問模型動態(tài)散列到其它數據節(jié)點hotzone上去訪問，集群中所有節(jié)點都會承擔這個功能。
通過這種方式，我們將原來單點訪問承擔的流量通過集群中部分機器來承擔。

可以看到，雙11零點的剎那，我們吸收了800多萬次的熱點訪問。如果沒有做熱點散列，散列前的指數都會超過死亡水位線。

寫熱點

寫熱點與讀熱點有類似的地方，也需要把熱點實時識別出來，然后通過IO線程把有熱點key的請求放給合并線程去處理，會有定時處理線程提交給存儲層。

經過雙11考驗對讀寫熱點的處理，我們現(xiàn)在可以放心的說，我們將緩存包括kv存儲部分的讀寫熱點徹底解決了。

總結

以上是生活随笔為你收集整理的双11万亿流量下的分布式缓存的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。