摘要：
12月13-14日，由雲棲社群與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背後的黑科技。本文是《雙11萬億流量下的分布式快取》演講整理，本文主要從tair發展和應用開始談起，接著談及雙11面臨的挑戰，重點分享了效能優化方面的實踐，最後對快取難題給出了解決方案。
12月13-14日，由雲棲社群與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背後的黑科技。本文是《雙11萬億流量下的分布式快取》演講整理，本文主要從tair發展和應用開始談起，接著談及雙11面臨的挑戰，重點分享了效能優化方面的實踐，最後對快取難題給出了解決方案。內容如下。
分享嘉賓：
宗岱：阿里巴巴資深技術專家，2023年加入**，阿里分布式快取、nosql資料庫tair和tengine負責人。
tair概覽
tair發展歷程
tair是乙個高效能、分布式、可擴充套件、高可靠的key/value結構儲存系統！tair特性主要體現在以下幾個方面：
tair除了普通key/value系統提供的功能，比如get、put、delete以及批量介面外，還有一些附加的實用功能，使得其有更廣的適用場景。tair應用場景包括以下四種：
1. mdb 典型應用場景：用於快取，降低對後端資料庫的訪問壓力，比如**中的商品都是快取在tair中；用於臨時資料儲存，部分資料丟失不會對業務產生較大影響；讀多寫少，讀qps達到萬級別以上。
2. ldb 典型應用場景：通用kv儲存、交易快照、安全風控等；儲存黑白單資料，讀qps很高；計數器功能，更新非常頻繁，且資料不可丟失。
雙 11 挑戰怎麼辦？
2012-2023年資料如圖，可以看到，2023年gmv小於200億，2023年gmv達到1682億，交易建立峰值從1.4萬達到32.5萬，峰值qps從1300萬達到近5億。我們可以得出，tair訪問峰值增速：tair峰值 > 交易峰值 > 總gmv，如何確保成本不超過交易峰值增速？對於帶資料的分布式系統來說，快取問題都是比較難解決的，快取流量特別大，2023年雙11後，我們徹底解決掉了快取問題。我們現在的交易系統和匯入系統都是多地域多單元多機房部署的，如何快速部署業務系統呢？
多地域多單元
多地域多單元首先是中心機房，我們做了雙機房容災，兩側還有若干個單元。機房內系統圖如圖，從流量接入進統一接入層-應用層-中介軟體-tair-db，在資料層我們會做多地域的資料同步。
彈性建站
我們需要系統具備彈性建站的能力。tair是乙個複雜的分布式儲存系統，我們為之建立了一整套運營管控系統泰斗，在泰斗裡建設彈性建站系統，它會經過一系列工作步驟將tair系統建設起來，我們還會從系統層面、集群層面和例項連通層面進行驗證，以確保系統功能、穩定性萬無一失。
tair的每乙個業務集群水位其實是不一樣的，雙11前的每一次全鏈路壓測下，由於業務模型的變化，所用tair資源會發生變化，造成水位出現變化。在此情況下，我們需要每一次壓測完在多個集群間排程tair資源，如果水位低，就會把某些機器伺服器資源往水位高挪，達到所有集群水位值接近。
資料同步
對於單元化業務，我們提供了本單元訪問本地tair的能力，對於有些非單元化業務，我們也提供了更靈活的訪問模型。同步延遲是我們一直在做的事情，2023年雙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承擔熱點資料儲存。對於整個方案來說，最關鍵有以下幾步：
通過這種方式，我們將原來單點訪問承擔的流量通過集群中部分機器來承擔。
可以看到，雙11零點的剎那，我們吸收了800多萬次的熱點訪問。如果沒有做熱點雜湊，雜湊前的指數都會超過死亡水位線。
寫熱點
寫熱點與讀熱點有類似的地方，也需要把熱點實時識別出來，然後通過io執行緒把有熱點key的請求放給合併執行緒去處理，會有定時處理執行緒提交給儲存層。
經過雙11考驗對讀寫熱點的處理，我們現在可以放心的說，我們將快取包括kv儲存部分的讀寫熱點徹底解決了。
分布式快取的面試題11
1 面試題 生產環境中的redis是怎麼部署的？2 面試官心裡分析 看看你了解不了解你們公司的redis生產集群的部署架構，如果你不了解，那麼確實你就很失職了，你的 redis 是主從架構？集群架構？用了哪種集群方案？有沒有做高可用保證？有沒有開啟持久化機制確保可以進行資料恢復？線上 redis 給...
Hadoop的分布式快取
hadoop的分布式快取 1.什麼時hadoop的分布式快取 2.如何使用快取機制 答 在main方法中載入共享檔案的hdfs路徑，路徑可以是目錄也可以是檔案。可以在路徑末尾階段追加 別名，在map階段可以使用該別名。這時執行第一步的 string cache hdfs 目錄或者檔案 cache m...
分布式的多級快取
所謂分布式多級快取，就是指在整個系統的不同層級進行資料的快取，以提公升系統的訪問速度。通常情況下，分布式系統的訪問流程如下所示 1 接入層nginx將請求負載均衡到應用層nginx，常用的負載均衡演算法是輪詢 一致性雜湊。輪詢可以是請求更加的平均，一致性雜湊可以提公升應用層nginx的快取命中率。2...