雙11萬億流量下的分佈式緩存

摘要： 12月13-14日，由雲棲社區與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中爲你們分享了2017雙11背後的黑科技。本文是《雙11萬億流量下的分佈式緩存》演講整理，本文主要從Tair發展和應用開始談起，接着談及雙11面臨的挑戰，重點分享了性能優化方面的實踐，最後對緩存難題給出瞭解決方案。

12月13-14日，由雲棲社區與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中爲你們分享了2017雙11背後的黑科技。本文是《雙11萬億流量下的分佈式緩存》演講整理，本文主要從Tair發展和應用開始談起，接着談及雙11面臨的挑戰，重點分享了性能優化方面的實踐，最後對緩存難題給出瞭解決方案。內容以下。

分享嘉賓：

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

Tair概覽

Tair發展歷程

Tair在阿里巴巴被普遍使用，不管是淘寶天貓瀏覽下單，仍是打開優酷瀏覽播放時，背後都有Tair的身影默默支撐巨大的流量。Tair的發展歷程以下：

2010.04 Tair v1.0正式推出@淘寶核心系統；
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結構存儲系統！Tair特性主要體如今如下幾個方面：

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

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

1. MDB 典型應用場景：用於緩存，下降對後端數據庫的訪問壓力，好比淘寶中的商品都是緩存在Tair中；用於臨時數據存儲，部分數據丟失不會對業務產生較大影響；讀多寫少，讀qps達到萬級別以上。
2. LDB 典型應用場景：通用kv存儲、交易快照、安全風控等；存儲黑白單數據，讀qps很高；計數器功能，更新很是頻繁，且數據不可丟失。
3. RDB 典型應用場景：複雜的數據結構的緩存與存儲，如播放列表，直播間等。
4. FastDump 典型應用場景：週期性地將離線數據快速地導入到Tair集羣中，快速使用到新的數據，對在線讀取要求很是高；讀取低延遲，不能有毛刺。

雙 11 挑戰怎麼辦？

2012-2017年數據如圖，能夠看到，2012年GMV小於200億，2017年GMV達到1682億，交易建立峯值從1.4萬達到32.5萬，峯值QPS從1300萬達到近5億。咱們能夠得出，Tair訪問峯值增速：Tair峯值 > 交易峯值 > 總GMV，如何確保成本不超過交易峯值增速？對於帶數據的分佈式系統來講，緩存問題都是比較難解決的，緩存流量特別大，2017年雙11後，咱們完全解決掉了緩存問題。咱們如今的交易系統和導入系統都是多地域多單元多機房部署的，如何快速部署業務系統呢？

多地域多單元

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

彈性建站

咱們須要系統具有彈性建站的能力。Tair是一個複雜的分佈式存儲系統，咱們爲之創建了一整套運營管控系統泰斗，在泰斗裏建設彈性建站系統，它會通過一系列工做步驟將Tair系統建設起來，咱們還會從系統層面、集羣層面和實例連通層面進行驗證，以確保系統功能、穩定性萬無一失。

Tair的每個業務集羣水位實際上是不同的，雙11前的每一次全鏈路壓測下，因爲業務模型的變化，所用Tair資源會發生變化，形成水位出現變化。在此狀況下，咱們須要每一次壓測完在多個集羣間調度Tair資源，若是水位低，就會把某些機器服務器資源往水位高挪，達到全部集羣水位值接近。

數據同步

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

性能優化降成本

服務器成本並非隨着訪問量線性增加，每一年以百分之三四十成本在降低，咱們主要經過服務器性能優化、客戶端性能優化和不一樣的業務解決方案三方面達到此目的。

內存數據結構

圖爲MDB內存數據結構示意圖，咱們在進程啓動以後會申請一大塊內存，在內存中將格式組織起來。主要有slab分配器、hashmap和內存池，內存寫滿後會通過LRU鏈進行數據淘汰。隨着服務器CPU核數不斷增長，若是不能很好處理鎖競爭，很難提高總體性能。

參考了各類文獻和操做系統的設計，咱們使用了細粒度鎖、無鎖數據結構、CPU本地數據結構和讀拷貝更新（讀鏈表時不須要加鎖）。左圖爲未通過優化時鎖競爭各個功能模塊消耗圖，能夠看到網絡部分和數據查找部分消耗最多，優化後（右圖）有80%的處理都是在網絡和數據查找，這是符合咱們指望的。

用戶態協議棧

鎖優化後，咱們發現不少CPU消耗在內核態上，這時咱們採用DPDK+Alisocket來替換掉原有內核態協議棧，Alisocket採用DPDK在用戶態進行網卡收包，並利用自身協議棧提供socket API，對其進行集成。咱們與業內相似系統進行了對比，如圖。

內存合併

單機性能提高足夠高後，帶來問題是單位qps對應內存量變少了，怎麼解決呢？咱們發現公用集羣總體看內存仍是有的，某些slab沒有辦法寫入， 好比64字節slab沒有被寫滿，可是72字節slab所有寫滿了，內存池都被申請完了，咱們把64字節slab空閒頁相互合併，這樣能夠釋放大量空閒頁。其中不可避免加入模式鎖，在觸發合併閾值狀況下，切換成加鎖狀態，合併都是在訪問量低峯期作的，對於業務峯值來講沒有問題。

客戶端優化

客戶端咱們作了兩方面優化：網絡框架替換，適配協程，從原有的mina替換成netty，吞吐量提高40%；序列化優化，集成 kryo和hessian，吞吐量提高16%+。

內存網格

如何與業務結合來下降總體Tair與業務成本？Tair提供了多級存儲一體化解決業務問題，好比安全風控場景，讀寫量超大、有大量本地計算，咱們能夠在業務機器本地存下該業務機器所要訪問的數據，大量讀會命中在本地，並且寫在一段時間內是可合併的，在必定週期後，合併寫到遠端Tair集羣上做爲最終存儲。咱們提供讀寫穿透，包括合併寫和原有Tair自己具備多單元複製的能力，雙11時業務對Tair讀取降至27.68%，對Tair寫入降至55.75%。

熱點難題已解決

緩存擊穿

緩存從開始的單點發展到分佈式系統，經過數據分片方式組織，但對每個數據分片來講，仍是做爲單點存在的。當有大促活動或熱點新聞時，數據每每是在某一個分片上的，這就會形成單點訪問，進而緩存中某個節點就會沒法承受這麼大壓力，導致大量請求沒有辦法響應。即使是限流也是有損操做，可能也會形成全系統崩潰。咱們發現，問題根源是訪問熱點，須要完全解決該問題。

熱點散列

通過多種方案的探索，採用了熱點散列方案。咱們評估過客戶端本地cache方案和二級緩存方案，它們能夠在必定程度上解決熱點問題，但各有弊端。而熱點散列直接在數據節點上加hotzone區域，讓hotzone承擔熱點數據存儲。對於整個方案來講，最關鍵有如下幾步：

智能識別。熱點數據老是在變化的，或是頻率熱點，或是流量熱點。
實時反饋。採用多級LRU的數據結構，設定不一樣權值放到不一樣層級的LRU上，一旦LRU數據寫滿後，會從低級LRU鏈開始淘汰，確保權值高的獲得保留。
動態散列。當訪問到熱點時，Appserver和服務端就會聯動起來，根據預先設定好的訪問模型動態散列到其它數據節點hotzone上去訪問，集羣中全部節點都會承擔這個功能。
經過這種方式，咱們將原來單點訪問承擔的流量經過集羣中部分機器來承擔。

能夠看到，雙11零點的剎那，咱們吸取了800多萬次的熱點訪問。若是沒有作熱點散列，散列前的指數都會超過死亡水位線。

寫熱點

寫熱點與讀熱點有相似的地方，也須要把熱點實時識別出來，而後經過IO線程把有熱點key的請求放給合併線程去處理，會有定時處理線程提交給存儲層。

通過雙11考驗對讀寫熱點的處理，咱們如今能夠放心的說，咱們將緩存包括kv存儲部分的讀寫熱點完全解決了。