揭秘！雙11萬(wàn)億流量下的分布式緩存系統(tǒng) Tair，真的了不起

阿里妹導(dǎo)讀：本文以雙11面臨的挑戰(zhàn)為背景，從Tair（阿里自研高速緩存系統(tǒng)）發(fā)展和應(yīng)用開(kāi)始談起，重點(diǎn)分享了性能優(yōu)化方面的實(shí)踐，最后對(duì)緩存熱點(diǎn)難題給出了解決方案，希望能對(duì)大家的工作有所啟發(fā)。
本文作者為宗岱，阿里巴巴資深技術(shù)專家，2008年加入淘寶，阿里分布式緩存、NoSQL數(shù)據(jù)庫(kù)Tair和Tengine負(fù)責(zé)人。

Tair概覽

Tair發(fā)展歷程

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

• 2010.04 Tair v1.0正式推出@淘寶核心系統(tǒng)；

• 2012.06 Tair v2.0推出LDB持久化產(chǎn)品，滿足持久化存儲(chǔ)需求；

• 2012.10 推出RDB緩存產(chǎn)品，引入類Redis接口，滿足復(fù)雜數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)需求；

• 2013.03 在LDB的基礎(chǔ)上針對(duì)全量導(dǎo)入場(chǎng)景上線Fastdump產(chǎn)品，大幅度降低導(dǎo)入時(shí)間和訪問(wèn)延時(shí)；

• 2014.07 Tair v3.0 正式上線，性能數(shù)倍提升；

• 2016.11 泰斗智能運(yùn)維平臺(tái)上線，助力2016雙11邁入千億時(shí)代；

• 2017.11 性能飛躍，熱點(diǎn)散列，資源調(diào)度，支持萬(wàn)億流量。

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

• 高性能：在高吞吐下保證低延遲，Tair是阿里集團(tuán)內(nèi)調(diào)用量最大系統(tǒng)之一，雙11達(dá)到每秒5億次峰值的調(diào)用量，平均訪問(wèn)延遲在1毫秒以下；

• 高可用：通過(guò)自動(dòng)failover，限流，審計(jì)和機(jī)房?jī)?nèi)容災(zāi)以及多單元多地域，確保系統(tǒng)在任何情況下都能正常運(yùn)行；

• 規(guī)模化：分布全球各個(gè)數(shù)據(jù)中心，阿里集團(tuán)各個(gè)BU都在使用；

• 業(yè)務(wù)覆蓋：電商、螞蟻、合一、菜鳥(niǎo)、高德、阿里健康等。

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

1. MDB 典型應(yīng)用場(chǎng)景：用于緩存，降低對(duì)后端數(shù)據(jù)庫(kù)的訪問(wèn)壓力，比如淘寶中的商品都是緩存在Tair中；用于臨時(shí)數(shù)據(jù)存儲(chǔ)，部分?jǐn)?shù)據(jù)丟失不會(huì)對(duì)業(yè)務(wù)產(chǎn)生較大影響，例如登陸；

2. LDB 典型應(yīng)用場(chǎng)景：通用kv存儲(chǔ)、交易快照、安全風(fēng)控等；存儲(chǔ)黑白單數(shù)據(jù)，讀qps很高；計(jì)數(shù)器功能，更新非常頻繁，且數(shù)據(jù)不可丟失。

3. RDB 典型應(yīng)用場(chǎng)景：復(fù)雜的數(shù)據(jù)結(jié)構(gòu)的緩存與存儲(chǔ)，如播放列表，直播間等。

4. FastDump 典型應(yīng)用場(chǎng)景：周期性地將離線數(shù)據(jù)快速地導(dǎo)入到Tair集群中，快速使用到新的數(shù)據(jù)，對(duì)在線讀取要求非常高；讀取低延遲，不能有毛刺。

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

2012-2017年數(shù)據(jù)如圖，可以看到，2012年GMV小于200億，2017年GMV達(dá)到1682億，交易創(chuàng)建峰值從1.4萬(wàn)達(dá)到32.5萬(wàn)，峰值QPS從1300萬(wàn)達(dá)到近5億。

從圖中可以看出，tair訪問(wèn)增速遠(yuǎn)大于交易創(chuàng)建峰值，交易創(chuàng)建峰值也大于GMV的增長(zhǎng)。也就是0點(diǎn)的那刻，對(duì)Tair來(lái)說(shuō)，在保證高并發(fā)訪問(wèn)的同時(shí)，如何確保低延遲，如何確保成本低于業(yè)務(wù)增速的技術(shù)挑戰(zhàn)越來(lái)越大。

對(duì)于分布式存儲(chǔ)系統(tǒng)來(lái)說(shuō)，熱點(diǎn)問(wèn)題都是比較難解決的。而緩存系統(tǒng)流量特別大，熱點(diǎn)問(wèn)題更為突出。2017年雙11，我們通過(guò)了熱點(diǎn)散列，徹底解決掉了緩存熱點(diǎn)問(wèn)題。

同時(shí)，為了承載每秒32.5萬(wàn)筆交易阿里的技術(shù)架構(gòu)也不斷演進(jìn)成為多地域多單元的架構(gòu)，不僅采用了阿里云上的單元，而且也有和離線服務(wù)混部的單元，這里對(duì)我們的挑戰(zhàn)是如何快速?gòu)椥缘牟渴鸷拖戮€集群。

多地域多單元

先看下我們大致整體的部署架構(gòu)和tair在系統(tǒng)中的位置。從這張簡(jiǎn)圖上看到，我們是一個(gè)多地域多機(jī)房多單元的部署架構(gòu)。整個(gè)系統(tǒng)上從流量的接入層，到應(yīng)用層。然后應(yīng)用層依賴了各種中間件，例如消息隊(duì)列，配置中心等等。最底層是基礎(chǔ)的數(shù)據(jù)層，tair和數(shù)據(jù)庫(kù)。在數(shù)據(jù)這一層，我們需要為業(yè)務(wù)做需要的數(shù)據(jù)同步，以保障上層業(yè)務(wù)是無(wú)狀態(tài)的。

多地域多單元除了防止黑天鵝之外，另外一個(gè)重要的作用是能夠通過(guò)快速上線一個(gè)單元來(lái)實(shí)現(xiàn)承載部分的流量。Tair也做了一整套控制系統(tǒng)來(lái)實(shí)現(xiàn)快速的彈性建站。

彈性建站

Tair本身是一個(gè)很復(fù)雜分布式存儲(chǔ)系統(tǒng)，規(guī)模也非常龐大。所以我們有一個(gè)叫泰斗的運(yùn)營(yíng)管理平臺(tái)。在這里面通過(guò)任務(wù)編排，任務(wù)執(zhí)行，驗(yàn)證和交付等流程來(lái)確保快速的一鍵建站，離在線混部集群的快上快下工作。在部署工作完成后，會(huì)經(jīng)過(guò)一系列系統(tǒng)，集群，實(shí)例上的連通性驗(yàn)證來(lái)確保服務(wù)完整無(wú)誤后，再交付上線使用。如果有一絲遺漏，那么業(yè)務(wù)流量過(guò)來(lái)時(shí)，可能會(huì)觸發(fā)大規(guī)模故障。這里面，如果是帶數(shù)據(jù)的持久化集群，那么在部署完成后，還需要等待存量數(shù)據(jù)遷移完成并且數(shù)據(jù)達(dá)到同步后才能進(jìn)入驗(yàn)證階段。

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

數(shù)據(jù)同步

多地域多單元，必須要求我們數(shù)據(jù)層能夠做到數(shù)據(jù)的同步，并且能夠提供給業(yè)務(wù)各種不同的讀寫模式。對(duì)于單元化業(yè)務(wù)，我們提供了本單元訪問(wèn)本地Tair的能力，對(duì)于有些非單元化業(yè)務(wù)，我們也提供了更靈活的訪問(wèn)模型。同步延遲是我們一直在做的事情，2017年雙11每秒同步數(shù)據(jù)已經(jīng)達(dá)到了千萬(wàn)級(jí)別，那么，如何更好地解決非單元化業(yè)務(wù)在多單元寫入數(shù)據(jù)沖突問(wèn)題？這也是我們一直考慮的。

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

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

先來(lái)看下我們?nèi)绾螐姆?wù)端角度提升性能和降低成本的。這里的工作主要分為兩大塊：一塊是避免線程切換調(diào)度，降低鎖競(jìng)爭(zhēng)和無(wú)鎖化，另外一塊是采用用戶態(tài)協(xié)議棧+DPDK來(lái)將run-to-completion進(jìn)行到底。

內(nèi)存數(shù)據(jù)結(jié)構(gòu)

MDB內(nèi)存數(shù)據(jù)結(jié)構(gòu)示意圖

我們?cè)谶M(jìn)程啟動(dòng)之后會(huì)申請(qǐng)一大塊內(nèi)存，在內(nèi)存中將格式組織起來(lái)。主要有slab分配器、hashmap和內(nèi)存池，內(nèi)存寫滿后會(huì)經(jīng)過(guò)LRU鏈進(jìn)行數(shù)據(jù)淘汰。隨著服務(wù)器CPU核數(shù)不斷增加，如果不能很好處理鎖競(jìng)爭(zhēng)，很難提升整體性能。

通過(guò)參考各種文獻(xiàn)，并結(jié)合tair自身引擎需求，我們使用了細(xì)粒度鎖、無(wú)鎖數(shù)據(jù)結(jié)構(gòu)、CPU本地?cái)?shù)據(jù)結(jié)構(gòu)和RCU機(jī)制來(lái)提升引擎的并行性。左圖為未經(jīng)過(guò)優(yōu)化時(shí)各個(gè)功能模塊的CPU消耗圖，可以看到網(wǎng)絡(luò)部分和數(shù)據(jù)查找部分消耗最多，優(yōu)化后（右圖）有80%的處理都是在網(wǎng)絡(luò)和數(shù)據(jù)的查找，這是符合我們期望的。

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

鎖優(yōu)化后，我們發(fā)現(xiàn)很多CPU消耗在內(nèi)核態(tài)上，這時(shí)我們采用DPDK+Alisocket來(lái)替換掉原有內(nèi)核態(tài)協(xié)議棧，Alisocket采用DPDK在用戶態(tài)進(jìn)行網(wǎng)卡收包，并利用自身協(xié)議棧提供socket API，對(duì)其進(jìn)行集成。我們將tair，memcached以及業(yè)內(nèi)以性能著稱的seastar框架相比，tair的性能優(yōu)勢(shì)在seastar 10%以上。

內(nèi)存合并

當(dāng)性能提升后，單位qps所占用的內(nèi)存就變少了，所以內(nèi)存變得很緊缺。另外一個(gè)現(xiàn)狀，tair是一個(gè)多租戶的系統(tǒng)，各個(gè)業(yè)務(wù)行為不太一樣，時(shí)常會(huì)造成page已經(jīng)分配完畢，但是很多slab里的page都是未寫滿的。而有少量slab確實(shí)已經(jīng)全占滿了，造成了看上去有容量，但無(wú)法分配數(shù)據(jù)的情況。

此時(shí)，我們實(shí)施了一個(gè)將同一slab里未寫滿page內(nèi)存合并的功能，可以釋放出大量空閑內(nèi)存。從圖中可以看到，在同一個(gè)slab里，記錄了每個(gè)page的使用率，并掛載到不同規(guī)格的bucket上。合并時(shí)，將使用率低的page往使用率高的page上合并。同時(shí)還需要將各個(gè)相關(guān)聯(lián)的數(shù)據(jù)結(jié)構(gòu)，包括LRU鏈，相當(dāng)于整個(gè)內(nèi)存結(jié)構(gòu)的重整。這個(gè)功能在線上的公用集群里效果特別好，根據(jù)不同場(chǎng)景，可以大幅提升內(nèi)存使用效率。

客戶端優(yōu)化

上面這些是服務(wù)端的變化，接下來(lái)看看客戶端的性能。我們的客戶端是運(yùn)行在客戶服務(wù)器上的，所以占用了客戶的資源。如果能盡可能低的降低資源消耗，對(duì)我們整個(gè)系統(tǒng)來(lái)說(shuō)，成本都是有利的?？蛻舳宋覀冏隽藘煞矫鎯?yōu)化：網(wǎng)絡(luò)框架替換，適配協(xié)程，從原有的mina替換成netty，吞吐量提升40%；序列化優(yōu)化，集成 kryo和hessian，吞吐量提升16%+。

內(nèi)存網(wǎng)格

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

熱點(diǎn)難題已解決

緩存擊穿

緩存從開(kāi)始的單點(diǎn)發(fā)展到分布式系統(tǒng)，通過(guò)數(shù)據(jù)分片方式組織，但對(duì)每一個(gè)數(shù)據(jù)分片來(lái)說(shuō)，還是作為單點(diǎn)存在的。當(dāng)有大促活動(dòng)或熱點(diǎn)新聞時(shí)，數(shù)據(jù)往往是在某一個(gè)分片上的，這就會(huì)造成單點(diǎn)訪問(wèn)，進(jìn)而緩存中某個(gè)節(jié)點(diǎn)就會(huì)無(wú)法承受這么大壓力，致使大量請(qǐng)求沒(méi)有辦法響應(yīng)。對(duì)于緩存系統(tǒng)一個(gè)自保的方法是限流。但是限流對(duì)于整個(gè)系統(tǒng)來(lái)說(shuō)，并無(wú)濟(jì)于事。限流后，一部分流量會(huì)去訪問(wèn)數(shù)據(jù)庫(kù)，那依然和剛剛所說(shuō)的無(wú)法承受是一樣的結(jié)果，整個(gè)系統(tǒng)出現(xiàn)異常。

所以在這里，唯一的解決辦法是緩存系統(tǒng)能夠作為流量的終結(jié)點(diǎn)。不管是大促，還是熱點(diǎn)新聞，還是業(yè)務(wù)自己的異常。緩存都能夠把這些流量吸收掉，并且能讓業(yè)務(wù)看到熱點(diǎn)的情況。

熱點(diǎn)散列

經(jīng)過(guò)多種方案的探索，采用了熱點(diǎn)散列方案。我們?cè)u(píng)估過(guò)客戶端本地cache方案和二級(jí)緩存方案，它們可以在一定程度上解決熱點(diǎn)問(wèn)題，但各有弊端。例如二級(jí)緩存的服務(wù)器數(shù)目無(wú)法預(yù)估，本地cache方案對(duì)的業(yè)務(wù)側(cè)內(nèi)存和性能的影響。而熱點(diǎn)散列直接在數(shù)據(jù)節(jié)點(diǎn)上加hotzone區(qū)域，讓hotzone承擔(dān)熱點(diǎn)數(shù)據(jù)存儲(chǔ)。對(duì)于整個(gè)方案來(lái)說(shuō)，最關(guān)鍵有以下幾步：

• 智能識(shí)別。熱點(diǎn)數(shù)據(jù)總是在變化的，或是頻率熱點(diǎn)，或是流量熱點(diǎn)。內(nèi)部實(shí)現(xiàn)采用多級(jí)LRU的數(shù)據(jù)結(jié)構(gòu)，設(shè)定不同權(quán)值放到不同層級(jí)的LRU上，一旦LRU數(shù)據(jù)寫滿后，會(huì)從低級(jí)LRU鏈開(kāi)始淘汰，確保權(quán)值高的得到保留。

• 實(shí)時(shí)反饋和動(dòng)態(tài)散列。當(dāng)訪問(wèn)到熱點(diǎn)時(shí)，appserver和服務(wù)端就會(huì)聯(lián)動(dòng)起來(lái)，根據(jù)預(yù)先設(shè)定好的訪問(wèn)模型動(dòng)態(tài)散列到其它數(shù)據(jù)節(jié)點(diǎn)hotzone上去訪問(wèn)，集群中所有節(jié)點(diǎn)都會(huì)承擔(dān)這個(gè)功能。

通過(guò)這種方式，我們將原來(lái)單點(diǎn)訪問(wèn)承擔(dān)的流量通過(guò)集群中部分機(jī)器來(lái)承擔(dān)。

整個(gè)工程實(shí)現(xiàn)是很復(fù)雜的，熱點(diǎn)散列在雙11中取得了非常顯著的效果。峰值每秒吸收了800多w的訪問(wèn)量。從右圖可以看到，紅色的線是如果未開(kāi)啟熱點(diǎn)散列的水位，綠色的線是開(kāi)啟熱點(diǎn)散列的水位。如果未開(kāi)啟，很多集群都超過(guò)了死亡水位，也就是我們集群水位的130%。而開(kāi)啟之后，通過(guò)將熱點(diǎn)散列到整個(gè)集群，水位降低到了安全線下。換而言之，如果不開(kāi)啟，那么很多集群都可能出現(xiàn)問(wèn)題。

寫熱點(diǎn)

寫熱點(diǎn)與讀熱點(diǎn)有類似的地方，這塊主要是通過(guò)合并寫操作來(lái)實(shí)施。首先依然是識(shí)別出熱點(diǎn)，如果是熱點(diǎn)寫操作，那么該請(qǐng)求會(huì)被分發(fā)到專門的熱點(diǎn)合并線程處理，該線程根據(jù)key對(duì)寫請(qǐng)求進(jìn)行一定時(shí)間內(nèi)的合并，隨后由定時(shí)線程按照預(yù)設(shè)的合并周期將合并后的請(qǐng)求提交到引擎層。通過(guò)這種方式來(lái)大幅降低引擎層的壓力。

經(jīng)過(guò)雙11考驗(yàn)對(duì)讀寫熱點(diǎn)的處理，我們可以放心的說(shuō)，Tair將緩存包括kv存儲(chǔ)部分的讀寫熱點(diǎn)徹底解決了。