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

Tair概覽

Tair發(fā)展歷程

成都創(chuàng)新互聯(lián)成立十多年來，這條路我們正越走越好，積累了技術(shù)與客戶資源，形成了良好的口碑。為客戶提供成都網(wǎng)站設(shè)計、成都做網(wǎng)站、網(wǎng)站策劃、網(wǎng)頁設(shè)計、域名注冊、網(wǎng)絡(luò)營銷、VI設(shè)計、網(wǎng)站改版、漏洞修補(bǔ)等服務(wù)。網(wǎng)站是否美觀、功能強(qiáng)大、用戶體驗好、性價比高、打開快等等，這些對于網(wǎng)站建設(shè)都非常重要，成都創(chuàng)新互聯(lián)通過對建站技術(shù)性的掌握、對創(chuàng)意設(shè)計的研究為客戶提供一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進(jìn)步。

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

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

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

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

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

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

• 2016.11 泰斗智能運維平臺上線，助力2016雙11邁入千億時代；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對于分布式存儲系統(tǒng)來說，熱點問題都是比較難解決的。而緩存系統(tǒng)流量特別大，熱點問題更為突出。2017年雙11，我們通過了熱點散列，徹底解決掉了緩存熱點問題。

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

多地域多單元

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

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

彈性建站

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

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

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

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

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

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

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

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

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

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

通過參考各種文獻(xiàn)，并結(jié)合tair自身引擎需求，我們使用了細(xì)粒度鎖、無鎖數(shù)據(jù)結(jié)構(gòu)、CPU本地數(shù)據(jù)結(jié)構(gòu)和RCU機(jī)制來提升引擎的并行性。左圖為未經(jīng)過優(yōu)化時各個功能模塊的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)上，這時我們采用DPDK+Alisocket來替換掉原有內(nèi)核態(tài)協(xié)議棧，Alisocket采用DPDK在用戶態(tài)進(jìn)行網(wǎng)卡收包，并利用自身協(xié)議棧提供socket API，對其進(jìn)行集成。我們將tair，memcached以及業(yè)內(nèi)以性能著稱的seastar框架相比，tair的性能優(yōu)勢在seastar 10%以上。

內(nèi)存合并

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

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

客戶端優(yōu)化

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

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

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

熱點難題已解決

緩存擊穿

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

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

熱點散列

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

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

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

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

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

寫熱點

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

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

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨有T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務(wù)器買多久送多久。

文章名稱：揭秘！雙11萬億流量下的分布式緩存系統(tǒng)Tair，真的了不起-創(chuàng)新互聯(lián)
當(dāng)前路徑：http://aaarwkj.com/article2/gdhic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、企業(yè)建站、定制開發(fā)、搜索引擎優(yōu)化、網(wǎng)站建設(shè)、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)