導讀：本文以雙11面臨的挑戰(zhàn)為背景鹿榜，從Tair（阿里自研高速緩存系統(tǒng)）發(fā)展和應用開始談起海雪，重點分享了性能優(yōu)化方面的實踐锦爵，最后對緩存熱點難題給出了解決方案，希望能對大家的工作有所啟發(fā)奥裸。
本文作者為宗岱险掀，阿里巴巴資深技術專家，2008年加入淘寶湾宙，阿里分布式緩存樟氢、NoSQL數(shù)據(jù)庫Tair和Tengine負責人。
Tair概覽
Tair發(fā)展歷程
Tair在阿里巴巴被廣泛使用侠鳄，無論是淘寶天貓瀏覽下單埠啃，還是打開優(yōu)酷瀏覽播放時，背后都有Tair的身影默默支撐巨大的流量伟恶。Tair的發(fā)展歷程如下：
(1). 2010.04 Tair v1.0正式推出@淘寶核心系統(tǒng)碴开；
(2).?2012.06 Tair v2.0推出LDB持久化產(chǎn)品，滿足持久化存儲需求博秫；
(3).?2012.10 推出RDB緩存產(chǎn)品潦牛，引入類Redis接口，滿足復雜數(shù)據(jù)結(jié)構(gòu)的存儲需求台盯；
(4).?2013.03 在LDB的基礎上針對全量導入場景上線Fastdump產(chǎn)品罢绽，大幅度降低導入時間和訪問延時；
(5).?2014.07 Tair v3.0 正式上線静盅，性能數(shù)倍提升良价；
(6).?2016.11 泰斗智能運維平臺上線，助力2016雙11邁入千億時代蒿叠；
(7).?2017.11 性能飛躍明垢，熱點散列，資源調(diào)度市咽，支持萬億流量痊银。
Tair是一個高性能、分布式施绎、可擴展溯革、高可靠的key/value結(jié)構(gòu)存儲系統(tǒng)！Tair特性主要體現(xiàn)在以下幾個方面：
(1).?高性能：在高吞吐下保證低延遲谷醉，Tair是阿里集團內(nèi)調(diào)用量最大系統(tǒng)之一致稀，雙11達到每秒5億次峰值的調(diào)用量，平均訪問延遲在1毫秒以下俱尼；
(2).?高可用：通過自動failover抖单，限流，審計和機房內(nèi)容災以及多單元多地域，確保系統(tǒng)在任何情況下都能正常運行矛绘；
(3).?規(guī)乃Ｐ荩化：分布全球各個數(shù)據(jù)中心，阿里集團各個BU都在使用货矮；
(4).?業(yè)務覆蓋：電商羊精、螞蟻、合一次屠、菜鳥园匹、高德、阿里健康等劫灶。
Tair除了普通Key/Value系統(tǒng)提供的功能裸违，比如get、put本昏、delete以及批量接口外供汛，還有一些附加的實用功能，使得其有更廣的適用場景涌穆。Tair應用場景包括以下四種：
(1).?MDB 典型應用場景：用于緩存怔昨，降低對后端數(shù)據(jù)庫的訪問壓力，比如淘寶中的商品都是緩存在Tair中宿稀；用于臨時數(shù)據(jù)存儲趁舀，部分數(shù)據(jù)丟失不會對業(yè)務產(chǎn)生較大影響，例如登陸祝沸；?
(2).?LDB 典型應用場景：通用kv存儲矮烹、交易快照、安全風控等罩锐；存儲黑白單數(shù)據(jù)奉狈，讀qps很高；計數(shù)器功能涩惑，更新非常頻繁仁期，且數(shù)據(jù)不可丟失。
(3).?RDB 典型應用場景：復雜的數(shù)據(jù)結(jié)構(gòu)的緩存與存儲竭恬，如播放列表跛蛋，直播間等。
(4).?FastDump 典型應用場景：周期性地將離線數(shù)據(jù)快速地導入到Tair集群中痊硕，快速使用到新的數(shù)據(jù)赊级，對在線讀取要求非常高；讀取低延遲寿桨，不能有毛刺。
雙 11 挑戰(zhàn)怎么辦？
2012-2017年數(shù)據(jù)如圖亭螟，可以看到挡鞍，2012年GMV小于200億，2017年GMV達到1682億预烙，交易創(chuàng)建峰值從1.4萬達到32.5萬墨微，峰值QPS從1300萬達到近5億。
從圖中可以看出扁掸，tair訪問增速遠大于交易創(chuàng)建峰值翘县，交易創(chuàng)建峰值也大于GMV的增長。也就是0點的那刻谴分，對Tair來說锈麸，在保證高并發(fā)訪問的同時，如何確保低延遲牺蹄，如何確保成本低于業(yè)務增速的技術挑戰(zhàn)越來越大忘伞。
對于分布式存儲系統(tǒng)來說，熱點問題都是比較難解決的沙兰。而緩存系統(tǒng)流量特別大拍冠，熱點問題更為突出挖胃。2017年雙11，我們通過了熱點散列，徹底解決掉了緩存熱點問題罗洗。
同時，為了承載每秒32.5萬筆交易阿里的技術架構(gòu)也不斷演進成為多地域多單元的架構(gòu)悠垛，不僅采用了阿里云上的單元蕾额，而且也有和離線服務混部的單元，這里對我們的挑戰(zhàn)是如何快速彈性的部署和下線集群绩鸣。
多地域多單元
先看下我們大致整體的部署架構(gòu)和tair在系統(tǒng)中的位置怀大。從這張簡圖上看到，我們是一個多地域多機房多單元的部署架構(gòu)呀闻。整個系統(tǒng)上從流量的接入層化借，到應用層。然后應用層依賴了各種中間件捡多，例如消息隊列蓖康，配置中心等等。最底層是基礎的數(shù)據(jù)層垒手，tair和數(shù)據(jù)庫蒜焊。在數(shù)據(jù)這一層，我們需要為業(yè)務做需要的數(shù)據(jù)同步科贬，以保障上層業(yè)務是無狀態(tài)的泳梆。
多地域多單元除了防止黑天鵝之外鳖悠，另外一個重要的作用是能夠通過快速上線一個單元來實現(xiàn)承載部分的流量。Tair也做了一整套控制系統(tǒng)來實現(xiàn)快速的彈性建站优妙。
彈性建站
Tair本身是一個很復雜分布式存儲系統(tǒng)乘综，規(guī)模也非常龐大。所以我們有一個叫泰斗的運營管理平臺套硼。在這里面通過任務編排卡辰，任務執(zhí)行，驗證和交付等流程來確毙耙猓快速的一鍵建站九妈，離在線混部集群的快上快下工作。在部署工作完成后雾鬼，會經(jīng)過一系列系統(tǒng)萌朱，集群，實例上的連通性驗證來確保服務完整無誤后呆贿，再交付上線使用嚷兔。如果有一絲遺漏，那么業(yè)務流量過來時做入，可能會觸發(fā)大規(guī)模故障冒晰。這里面，如果是帶數(shù)據(jù)的持久化集群竟块，那么在部署完成后壶运，還需要等待存量數(shù)據(jù)遷移完成并且數(shù)據(jù)達到同步后才能進入驗證階段。
Tair的每一個業(yè)務集群水位其實是不一樣的浪秘，雙11前的每一次全鏈路壓測蒋情，由于業(yè)務模型的變化，所用Tair資源會發(fā)生變化耸携，造成水位出現(xiàn)變化棵癣。在此情況下，我們每次都需要壓測多個集群間調(diào)度的Tair資源夺衍。如果水位低狈谊，就會把某些機器服務器資源往水位高挪，達到所有集群水位值接近沟沙。
數(shù)據(jù)同步
多地域多單元河劝，必須要求我們數(shù)據(jù)層能夠做到數(shù)據(jù)的同步，并且能夠提供給業(yè)務各種不同的讀寫模式矛紫。對于單元化業(yè)務赎瞎，我們提供了本單元訪問本地Tair的能力，對于有些非單元化業(yè)務颊咬，我們也提供了更靈活的訪問模型务甥。同步延遲是我們一直在做的事情牡辽，2017年雙11每秒同步數(shù)據(jù)已經(jīng)達到了千萬級別，那么敞临，如何更好地解決非單元化業(yè)務在多單元寫入數(shù)據(jù)沖突問題催享？這也是我們一直考慮的。
性能優(yōu)化降成本
服務器成本并不是隨著訪問量線性增長哟绊，每年以百分之三四十成本在下降，我們主要通過服務器性能優(yōu)化痰憎、客戶端性能優(yōu)化和不同的業(yè)務解決方案三方面達到此目標票髓。
先來看下我們?nèi)绾螐姆斩私嵌忍嵘阅芎徒档统杀镜摹＿@里的工作主要分為兩大塊：一塊是避免線程切換調(diào)度铣耘，降低鎖競爭和無鎖化洽沟，另外一塊是采用用戶態(tài)協(xié)議棧+DPDK來將run-to-completion進行到底。
內(nèi)存數(shù)據(jù)結(jié)構(gòu)
我們在進程啟動之后會申請一大塊內(nèi)存蜗细，在內(nèi)存中將格式組織起來裆操。主要有slab分配器、hashmap和內(nèi)存池炉媒，內(nèi)存寫滿后會經(jīng)過LRU鏈進行數(shù)據(jù)淘汰踪区。隨著服務器CPU核數(shù)不斷增加，如果不能很好處理鎖競爭吊骤，很難提升整體性能缎岗。
通過參考各種文獻，并結(jié)合tair自身引擎需求白粉，我們使用了細粒度鎖传泊、無鎖數(shù)據(jù)結(jié)構(gòu)、CPU本地數(shù)據(jù)結(jié)構(gòu)和RCU機制來提升引擎的并行性鸭巴。左圖為未經(jīng)過優(yōu)化時各個功能模塊的CPU消耗圖眷细，可以看到網(wǎng)絡部分和數(shù)據(jù)查找部分消耗最多，優(yōu)化后（右圖）有80%的處理都是在網(wǎng)絡和數(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)進行網(wǎng)卡收包，并利用自身協(xié)議棧提供socket API楷兽，對其進行集成地熄。我們將tair，memcached以及業(yè)內(nèi)以性能著稱的seastar框架相比芯杀，tair的性能優(yōu)勢在seastar 10%以上端考。
內(nèi)存合并
當性能提升后雅潭，單位qps所占用的內(nèi)存就變少了，所以內(nèi)存變得很緊缺却特。另外一個現(xiàn)狀扶供，tair是一個多租戶的系統(tǒng)，各個業(yè)務行為不太一樣裂明，時常會造成page已經(jīng)分配完畢椿浓，但是很多slab里的page都是未寫滿的。而有少量slab確實已經(jīng)全占滿了闽晦，造成了看上去有容量扳碍，但無法分配數(shù)據(jù)的情況。
此時仙蛉，我們實施了一個將同一slab里未寫滿page內(nèi)存合并的功能笋敞，可以釋放出大量空閑內(nèi)存。從圖中可以看到荠瘪，在同一個slab里夯巷，記錄了每個page的使用率，并掛載到不同規(guī)格的bucket上哀墓。合并時趁餐，將使用率低的page往使用率高的page上合并。同時還需要將各個相關聯(lián)的數(shù)據(jù)結(jié)構(gòu)篮绰，包括LRU鏈澎怒，相當于整個內(nèi)存結(jié)構(gòu)的重整。這個功能在線上的公用集群里效果特別好阶牍，根據(jù)不同場景喷面，可以大幅提升內(nèi)存使用效率。
客戶端優(yōu)化
上面這些是服務端的變化走孽，接下來看看客戶端的性能惧辈。我們的客戶端是運行在客戶服務器上的，所以占用了客戶的資源磕瓷。如果能盡可能低的降低資源消耗盒齿，對我們整個系統(tǒng)來說，成本都是有利的困食”呶蹋客戶端我們做了兩方面優(yōu)化：網(wǎng)絡框架替換，適配協(xié)程硕盹，從原有的mina替換成netty符匾，吞吐量提升40%；序列化優(yōu)化瘩例，集成 kryo和hessian啊胶，吞吐量提升16%+甸各。
內(nèi)存網(wǎng)格
如何與業(yè)務結(jié)合來降低整體Tair與業(yè)務成本？Tair提供了多級存儲一體化解決業(yè)務問題焰坪，比如安全風控場景趣倾，讀寫量超大、有大量本地計算某饰，我們可以在業(yè)務機器本地存下該業(yè)務機器所要訪問的數(shù)據(jù)儒恋，大量讀會命中在本地，而且寫在一段時間內(nèi)是可合并的黔漂，在一定周期后碧浊，合并寫到遠端Tair集群上作為最終存儲。我們提供讀寫穿透瘟仿，包括合并寫和原有Tair本身具有多單元復制的能力，雙11時業(yè)務對Tair讀取降至27.68%比勉，對Tair寫入降至55.75%劳较。
熱點難題已解決
緩存擊穿
緩存從開始的單點發(fā)展到分布式系統(tǒng)，通過數(shù)據(jù)分片方式組織浩聋，但對每一個數(shù)據(jù)分片來說观蜗，還是作為單點存在的。當有大促活動或熱點新聞時衣洁，數(shù)據(jù)往往是在某一個分片上的墓捻，這就會造成單點訪問，進而緩存中某個節(jié)點就會無法承受這么大壓力坊夫，致使大量請求沒有辦法響應砖第。對于緩存系統(tǒng)一個自保的方法是限流。但是限流對于整個系統(tǒng)來說环凿，并無濟于事梧兼。限流后，一部分流量會去訪問數(shù)據(jù)庫智听，那依然和剛剛所說的無法承受是一樣的結(jié)果羽杰，整個系統(tǒng)出現(xiàn)異常。
所以在這里到推，唯一的解決辦法是緩存系統(tǒng)能夠作為流量的終結(jié)點考赛。不管是大促，還是熱點新聞莉测，還是業(yè)務自己的異常颜骤。緩存都能夠把這些流量吸收掉，并且能讓業(yè)務看到熱點的情況捣卤。
熱點散列
經(jīng)過多種方案的探索复哆，采用了熱點散列方案欣喧。我們評估過客戶端本地cache方案和二級緩存方案，它們可以在一定程度上解決熱點問題梯找，但各有弊端唆阿。例如二級緩存的服務器數(shù)目無法預估，本地cache方案對的業(yè)務側(cè)內(nèi)存和性能的影響锈锤。而熱點散列直接在數(shù)據(jù)節(jié)點上加hotzone區(qū)域驯鳖，讓hotzone承擔熱點數(shù)據(jù)存儲。對于整個方案來說久免，最關鍵有以下幾步：
智能識別浅辙。熱點數(shù)據(jù)總是在變化的，或是頻率熱點阎姥，或是流量熱點记舆。內(nèi)部實現(xiàn)采用多級LRU的數(shù)據(jù)結(jié)構(gòu)，設定不同權(quán)值放到不同層級的LRU上呼巴，一旦LRU數(shù)據(jù)寫滿后泽腮，會從低級LRU鏈開始淘汰，確保權(quán)值高的得到保留衣赶。
實時反饋和動態(tài)散列诊赊。當訪問到熱點時，appserver和服務端就會聯(lián)動起來府瞄，根據(jù)預先設定好的訪問模型動態(tài)散列到其它數(shù)據(jù)節(jié)點hotzone上去訪問碧磅，集群中所有節(jié)點都會承擔這個功能。
通過這種方式遵馆，我們將原來單點訪問承擔的流量通過集群中部分機器來承擔鲸郊。
整個工程實現(xiàn)是很復雜的，熱點散列在雙11中取得了非常顯著的效果货邓。峰值每秒吸收了800多w的訪問量严望。從右圖可以看到，紅色的線是如果未開啟熱點散列的水位逻恐，綠色的線是開啟熱點散列的水位像吻。如果未開啟，很多集群都超過了死亡水位复隆，也就是我們集群水位的130%拨匆。而開啟之后，通過將熱點散列到整個集群挽拂，水位降低到了安全線下惭每。換而言之，如果不開啟，那么很多集群都可能出現(xiàn)問題台腥。
寫熱點
寫熱點與讀熱點有類似的地方宏赘，這塊主要是通過合并寫操作來實施。首先依然是識別出熱點黎侈，如果是熱點寫操作察署，那么該請求會被分發(fā)到專門的熱點合并線程處理，該線程根據(jù)key對寫請求進行一定時間內(nèi)的合并峻汉，隨后由定時線程按照預設的合并周期將合并后的請求提交到引擎層贴汪。通過這種方式來大幅降低引擎層的壓力。
經(jīng)過雙11考驗對讀寫熱點的處理休吠，我們可以放心的說扳埂，Tair將緩存包括kv存儲部分的讀寫熱點徹底解決了。
