[[420295]]

一 前言

在Redis的使用過程中，我們經(jīng)常會(huì)遇到BigKey（下文將其稱為“大key”）及HotKey（下文將其稱為“熱key”）。大Key與熱Key如果未能及時(shí)發(fā)現(xiàn)并進(jìn)行處理，很可能會(huì)使服務(wù)性能下降、用戶體驗(yàn)變差，甚至引發(fā)大面積故障。

二 大Key與熱Key的定義

我們經(jīng)常能夠在公司內(nèi)部的Redis開發(fā)使用規(guī)范手冊(cè)，或網(wǎng)絡(luò)中大量的Redis最佳實(shí)踐文章里看到有關(guān)大Key、熱Key的定義，然而這些資料中的大Key熱Key判定標(biāo)準(zhǔn)卻不盡相同，但可以明確的是，它們的判定維度是一致的：大Key通常都會(huì)以數(shù)據(jù)大小與成員數(shù)量來判定，而熱Key則以其接收到的請(qǐng)求頻率、數(shù)量來判定。

1 什么是大Key

通常我們會(huì)將含有較大數(shù)據(jù)或含有大量成員、列表數(shù)的Key稱之為大Key，下面我們將用幾個(gè)實(shí)際的例子對(duì)大Key的特征進(jìn)行描述：

一個(gè)STRING類型的Key，它的值為5MB（數(shù)據(jù)過大）
一個(gè)LIST類型的Key，它的列表數(shù)量為20000個(gè)（列表數(shù)量過多）
一個(gè)ZSET類型的Key，它的成員數(shù)量為10000個(gè)（成員數(shù)量過多）
一個(gè)HASH格式的Key，它的成員數(shù)量雖然只有1000個(gè)但這些成員的value總大小為100MB（成員體積過大）
需要注意的是，在以上的例子中，為了方便理解，我們對(duì)大Key的數(shù)據(jù)、成員、列表數(shù)給出了具體的數(shù)字。為了避免誤導(dǎo)，在實(shí)際業(yè)務(wù)中，大Key的判定仍然需要根據(jù)Redis的實(shí)際使用場(chǎng)景、業(yè)務(wù)場(chǎng)景來進(jìn)行綜合判斷。

2 什么是熱Key

在某個(gè)Key接收到的訪問次數(shù)、顯著高于其它Key時(shí)，我們可以將其稱之為熱Key，常見的熱Key如：

某Redis實(shí)例的每秒總訪問量為10000，而其中一個(gè)Key的每秒訪問量達(dá)到了7000（訪問次數(shù)顯著高于其它Key）
對(duì)一個(gè)擁有上千個(gè)成員且總大小為1MB的HASH Key每秒發(fā)送大量的HGETALL（帶寬占用顯著高于其它Key）
對(duì)一個(gè)擁有數(shù)萬個(gè)成員的ZSET Key每秒發(fā)送大量的ZRANGE（CPU時(shí)間占用顯著高于其它Key）

三 大Key與熱Key帶來的問題

在Redis的使用中，大Key及熱Key會(huì)給Redis帶來各種各樣的問題，而最常見的問題為性能下降、訪問超時(shí)、數(shù)據(jù)不均衡等。

1 大Key帶來的常見問題

Client發(fā)現(xiàn)Redis變慢；
Redis內(nèi)存不斷變大引發(fā)OOM，或達(dá)到maxmemory設(shè)置值引發(fā)寫阻塞或重要Key被逐出；
Redis Cluster中的某個(gè)node內(nèi)存遠(yuǎn)超其余node，但因Redis Cluster的數(shù)據(jù)遷移最小粒度為Key而無法將node上的內(nèi)存均衡化；
大Key上的讀請(qǐng)求使Redis占用服務(wù)器全部帶寬，自身變慢的同時(shí)影響到該服務(wù)器上的其它服務(wù)；
刪除一個(gè)大Key造成主庫(kù)較長(zhǎng)時(shí)間的阻塞并引發(fā)同步中斷或主從切換；

2 熱Key帶來的常見問題

熱Key占用大量的Redis CPU時(shí)間使其性能變差并影響其它請(qǐng)求；
Redis Cluster中各node流量不均衡造成Redis Cluster的分布式優(yōu)勢(shì)無法被Client利用，一個(gè)分片負(fù)載很高而其它分片十分空閑從而產(chǎn)生讀/寫熱點(diǎn)問題；
在搶購(gòu)、秒殺活動(dòng)中，由于商品對(duì)應(yīng)庫(kù)存Key的請(qǐng)求量過大超出Redis處理能力造成超賣；
熱Key的請(qǐng)求壓力數(shù)量超出Redis的承受能力造成緩存擊穿，此時(shí)大量強(qiáng)求將直接指向后端存儲(chǔ)將其打掛并影響到其它業(yè)務(wù)；
四 大Key與熱Key的常見產(chǎn)生原因
業(yè)務(wù)規(guī)劃不足、Redis不正確的使用、無效數(shù)據(jù)的堆積、訪問突增等都會(huì)產(chǎn)生大Key與熱Key，如：

將Redis用在并不適合其能力的場(chǎng)景，造成Key的value過大，如使用String類型的Key存放大體積二進(jìn)制文件型數(shù)據(jù)（大Key）；
業(yè)務(wù)上線前規(guī)劃設(shè)計(jì)考慮不足沒有對(duì)Key中的成員進(jìn)行合理的拆分，造成個(gè)別Key中的成員數(shù)量過多（大Key）；
沒有對(duì)無效數(shù)據(jù)進(jìn)行定期清理，造成如HASH類型Key中的成員持續(xù)不斷的增加（大Key）；
預(yù)期外的訪問量陡增，如突然出現(xiàn)的爆款商品、訪問量暴漲的熱點(diǎn)新聞、直播間某大主播搞活動(dòng)帶來的大量刷屏點(diǎn)贊、游戲中某區(qū)域發(fā)生多個(gè)工會(huì)間的戰(zhàn)斗涉及大量玩家等（熱Key）；
使用LIST類型Key的業(yè)務(wù)消費(fèi)側(cè)代碼故障，造成對(duì)應(yīng)Key的成員只增不減（大Key）；

五 找出Redis中的大Key與熱Key

大Key與熱Key的分析并不困難，我們有多種途徑和手段來對(duì)Redis中的Key進(jìn)行分析并找出其中的“問題”Key，如Redis的內(nèi)置功能、開源工具、阿里云Redis控制臺(tái)中的Key分析功能等。

1 使用Redis內(nèi)置功能發(fā)現(xiàn)大Key及熱Key

Redis內(nèi)置的一些命令、工具都可以幫助我們來發(fā)現(xiàn)這些問題Key。當(dāng)你對(duì)Redis的大Key熱Key已有明確的分析目標(biāo)時(shí)，可以通過如下命令對(duì)對(duì)應(yīng)Key進(jìn)行分析。

通過Redis內(nèi)置命令對(duì)目標(biāo)Key進(jìn)行分析

可能你會(huì)選擇使用debug object命令對(duì)Key進(jìn)行分析。該命令能夠根據(jù)傳入的對(duì)象（Key的名稱）來對(duì)Key進(jìn)行分析并返回大量數(shù)據(jù)，其中serializedlength的值為該Key的序列化長(zhǎng)度，你可能會(huì)選擇通過該數(shù)據(jù)來判斷對(duì)應(yīng)Key是否符合你的大Key判定標(biāo)準(zhǔn)。

需要注意的是，Key的序列化長(zhǎng)度并不等同于它在內(nèi)存空間中的真實(shí)長(zhǎng)度，此外，debug object屬于調(diào)試命令，運(yùn)行代價(jià)較大，并且在其運(yùn)行時(shí)，進(jìn)入Redis的其余請(qǐng)求將會(huì)被阻塞直到其執(zhí)行完畢。而該命令的運(yùn)行的時(shí)間長(zhǎng)短取決于傳入對(duì)象（Key名）序列化長(zhǎng)度的大小，因此，在線上環(huán)境中并不推薦使用該命令來分析大Key，這可能引發(fā)故障。

Redis自4.0起提供了MEMORY USAGE命令來幫助分析Key的內(nèi)存占用，相對(duì)debug object它的執(zhí)行代價(jià)更低，但由于其時(shí)間復(fù)雜度為O(N)因此在分析大Key時(shí)仍有阻塞風(fēng)險(xiǎn)。

我們建議通過風(fēng)險(xiǎn)更低方式來對(duì)Key進(jìn)行分析，Redis對(duì)于不同的數(shù)據(jù)結(jié)構(gòu)提供了不同的命令來返回其長(zhǎng)度或成員數(shù)量，如下表：

通過以上Redis內(nèi)置命令我們可以方便且安全的對(duì)Key進(jìn)行分析而不會(huì)影響線上服務(wù)，但由于它們返回的結(jié)果非Key的真實(shí)內(nèi)存占用數(shù)據(jù)，因此不夠精確，僅可作為參考。

通過Redis官方客戶端redis-cli的bigkeys參數(shù)發(fā)現(xiàn)大Key

如果你并無明確的目標(biāo)Key用于分析，而是希望通過工具找出整個(gè)Redis實(shí)例中的大Key，此時(shí)redis-cli的bigkeys參數(shù)能夠方便的幫你實(shí)現(xiàn)這個(gè)目標(biāo)。

Redis提供了bigkeys參數(shù)能夠使redis-cli以遍歷的方式分析整個(gè)Redis實(shí)例中的所有Key并匯總以報(bào)告的方式返回結(jié)果。該方案的優(yōu)勢(shì)在于方便及安全，而缺點(diǎn)也非常明顯：分析結(jié)果不可定制化。

bigkeys僅能分別輸出Redis六種數(shù)據(jù)結(jié)構(gòu)中的最大Key，如果你想只分析STRING類型或是找出全部成員數(shù)量超過10的HASH Key，那么bigkeys在此類需求場(chǎng)景下將無能為力。

GitHub上有大量的開源項(xiàng)目能夠?qū)崿F(xiàn)bigkeys的加強(qiáng)版使結(jié)果能夠按照配置定制化輸出，另外你可也以動(dòng)手使用SCAN + TYPE并配合上文表格中的命令自己實(shí)現(xiàn)一個(gè)Redis實(shí)例級(jí)的大Key分析工具。

同樣，該方案的實(shí)現(xiàn)方式及返回結(jié)果使其不具備精確性與實(shí)時(shí)性，建議僅作為參考。

通過Redis官方客戶端redis-cli的hotkeys參數(shù)發(fā)現(xiàn)熱Key

Redis自4.0起提供了hotkeys參數(shù)來方便用戶進(jìn)行實(shí)例級(jí)的熱Key分析功，該參數(shù)能夠返回所有Key的被訪問次數(shù)，它的缺點(diǎn)同樣為不可定制化輸出報(bào)告，大量的信息會(huì)使你在分析結(jié)果時(shí)復(fù)雜度較大，另外，使用該方案的前提條件是將redis-server的maxmemory-policy參數(shù)設(shè)置為L(zhǎng)FU。

通過業(yè)務(wù)層定位熱Key

指向Redis的每一次訪問都來自業(yè)務(wù)層，因此我們可以通過在業(yè)務(wù)層增加相應(yīng)的代碼對(duì)Redis的訪問進(jìn)行記錄并異步匯總分析。該方案的優(yōu)勢(shì)為能夠準(zhǔn)確并及時(shí)的分析出熱Key的存在，缺點(diǎn)為業(yè)務(wù)代碼復(fù)雜度的增加，同時(shí)可能會(huì)降低一些性能。

使用monitor命令在緊急情況時(shí)找出熱Key

Redis的monitor命令能夠忠實(shí)的打印Redis中的所有請(qǐng)求，包括時(shí)間信息、Client信息、命令以及Key信息。在發(fā)生緊急情況時(shí)，我們可以通過短暫執(zhí)行monitor命令并將輸出重定向至文件，在關(guān)閉monitor命令后通過對(duì)文件中請(qǐng)求進(jìn)行歸類分析即可找出這段時(shí)間中的熱Key。

由于monitor命令對(duì)Redis的CPU、內(nèi)存、網(wǎng)絡(luò)資源均有一定的占用。因此，對(duì)于一個(gè)已處于高壓狀態(tài)的Redis，monitor可能會(huì)起到雪上加霜的作用。同時(shí)，這種異步收集并分析的方案的時(shí)效性較差，并且由于分析的精確度取決于monitor的執(zhí)行時(shí)間，因此在多數(shù)無法長(zhǎng)時(shí)間執(zhí)行該命令的線上場(chǎng)景中本方案的精確度也不夠好。

2 使用開源工具發(fā)現(xiàn)大Key

Redis的高度流行使我們能夠方便的找到大量開源方案來解決我們當(dāng)前遇到的難題：在不影響線上服務(wù)的同時(shí)得到精確的分析報(bào)告。

使用redis-rdb-tools工具以定制化方式找出大Key

如果你希望按照自己的標(biāo)準(zhǔn)精確的分析一個(gè)Redis實(shí)例中所有Key的真實(shí)內(nèi)存占用并避免影響線上服務(wù)，在分析結(jié)束后得到一份簡(jiǎn)潔易懂的報(bào)告，redis-rdb-tools是非常好的選擇。

該工具能夠?qū)edis的RDB文件進(jìn)行定制化的分析，但由于分析RDB文件為離線工作，因此對(duì)線上服務(wù)不會(huì)有任何影響，這是它的最大優(yōu)點(diǎn)但同時(shí)也是它的最大缺點(diǎn)：離線分析代表著分析結(jié)果的較差時(shí)效性。對(duì)于一個(gè)較大的RDB文件，它的分析可能會(huì)持續(xù)很久很久。

3 依靠公有云的Redis分析服務(wù)發(fā)現(xiàn)大Key及熱Key

如果你期望能夠?qū)崟r(shí)的對(duì)Redis實(shí)例中的所有Key進(jìn)行分析并發(fā)現(xiàn)當(dāng)前存在的大Key及熱Key、了解Redis在運(yùn)行時(shí)間線中曾出現(xiàn)過哪些大Key熱Key，使自己對(duì)整個(gè)Redis實(shí)例的運(yùn)行狀態(tài)有一個(gè)全面而又準(zhǔn)確的判斷，那么公有云的Redis控制臺(tái)將能滿足這個(gè)需求。

阿里云Redis控制臺(tái)中的CloudDBA

CloudDBA是阿里云的數(shù)據(jù)庫(kù)智能服務(wù)系統(tǒng)，它支持Redis大Key與熱Key的實(shí)時(shí)分析、發(fā)現(xiàn)。

大Key及熱Key分析底層為阿里云Redis內(nèi)核的Key分析功能，該功能通過Redis內(nèi)核直接發(fā)現(xiàn)并輸出大Key熱Key的相關(guān)信息，因此，該功能的分析結(jié)果準(zhǔn)確性高效且對(duì)性能幾乎無任何影響，你可以通過點(diǎn)擊CloudDBA中的“Key分析”進(jìn)入該功能，如下圖1-1：

圖1-1：阿里云Redis控制臺(tái)CloudDBA

Key分析功能共有兩個(gè)頁面，它們?cè)试S在不同的時(shí)間維度對(duì)對(duì)應(yīng)Redis實(shí)例中的Key進(jìn)行分析：

實(shí)時(shí)：對(duì)當(dāng)前實(shí)例立即開始分析當(dāng)前實(shí)例，展示當(dāng)前存在的所有大Key及熱Key。
歷史：展示該實(shí)例近期曾出現(xiàn)過的大Key及熱Key，在歷史頁面中，所有出現(xiàn)過的大Key及熱Key都會(huì)被記錄，哪怕這些Key當(dāng)前已經(jīng)不存在。該功能能夠很好的反映Redis的歷史Key狀態(tài)，幫助追溯過去或現(xiàn)場(chǎng)已遭破壞的問題。

六 大Key與熱Key的處理

現(xiàn)在，我們已經(jīng)通過多種手段找到了Redis中的問題Key，那么我們應(yīng)當(dāng)立即著手對(duì)他們進(jìn)行處理，避免它們?cè)谥蟮臅r(shí)間中引發(fā)問題。

1 大Key的常見處理辦法

對(duì)大Key進(jìn)行拆分

如將一個(gè)含有數(shù)萬成員的HASH Key拆分為多個(gè)HASH Key，并確保每個(gè)Key的成員數(shù)量在合理范圍，在Redis Cluster結(jié)構(gòu)中，大Key的拆分對(duì)node間的內(nèi)存平衡能夠起到顯著作用。

對(duì)大Key進(jìn)行清理

將不適合Redis能力的數(shù)據(jù)存放至其它存儲(chǔ)，并在Redis中刪除此類數(shù)據(jù)。需要注意的是，我們已在上文提到一個(gè)過大的Key可能引發(fā)Redis集群同步的中斷，Redis自4.0起提供了UNLINK命令，該命令能夠以非阻塞的方式緩慢逐步的清理傳入的Key，通過UNLINK，你可以安全的刪除大Key甚至特大Key。

時(shí)刻監(jiān)控Redis的內(nèi)存水位

突然出現(xiàn)的大Key問題會(huì)讓我們措手不及，因此，在大Key產(chǎn)生問題前發(fā)現(xiàn)它并進(jìn)行處理是保持服務(wù)穩(wěn)定的重要手段。我們可以通過監(jiān)控系統(tǒng)并設(shè)置合理的Redis內(nèi)存報(bào)警閾值來提醒我們此時(shí)可能有大Key正在產(chǎn)生，如：Redis內(nèi)存使用率超過70%，Redis內(nèi)存1小時(shí)內(nèi)增長(zhǎng)率超過20%等。

通過此類監(jiān)控手段我們可以在問題發(fā)生前解決問題，如：LIST的消費(fèi)程序故障造成對(duì)應(yīng)Key的列表數(shù)量持續(xù)增長(zhǎng)，將告警轉(zhuǎn)變?yōu)轭A(yù)警從而避免故障的發(fā)生。

對(duì)失效數(shù)據(jù)進(jìn)行定期清理

例如我們會(huì)在HASH結(jié)構(gòu)中以增量的形式不斷寫入大量數(shù)據(jù)而忽略了這些數(shù)據(jù)的時(shí)效性，這些大量堆積的失效數(shù)據(jù)會(huì)造成大Key的產(chǎn)生，可以通過定時(shí)任務(wù)的方式對(duì)失效數(shù)據(jù)進(jìn)行清理。在此類場(chǎng)景中，建議使用HSCAN并配合HDEL對(duì)失效數(shù)據(jù)進(jìn)行清理，這種方式能夠在不阻塞的前提下清理無效數(shù)據(jù)。

使用阿里云的Tair(Redis企業(yè)版)服務(wù)避開失效數(shù)據(jù)的清理工作

如果你的HASH Key過多，同時(shí)存在大量的成員失效需要被清理的問題。由于大量Key與大量失效數(shù)據(jù)的疊加，在此類場(chǎng)景中定時(shí)任務(wù)已無法做到對(duì)無效數(shù)據(jù)進(jìn)行及時(shí)的清理，阿里云的Tair服務(wù)能夠很好的解決此類問題。

Tair是阿里云的Redis企業(yè)版，它在具備Redis所有特性（包括Redis的高性能特點(diǎn)）的同時(shí)提供了大量額外的高級(jí)功能。

TairHash是一種可為field設(shè)置過期時(shí)間和版本的hash類型數(shù)據(jù)結(jié)構(gòu)，它不但和Redis Hash一樣支持豐富的數(shù)據(jù)接口和高處理性能，還改變了hash只能為key設(shè)置過期時(shí)間的限制：TairHash允許為field設(shè)置過期時(shí)間和版本。這極大地提高了hash數(shù)據(jù)結(jié)構(gòu)的靈活性，簡(jiǎn)化了很多場(chǎng)景下的業(yè)務(wù)開發(fā)工作。

TairHash使用高效的Active Expire算法，實(shí)現(xiàn)了在對(duì)響應(yīng)時(shí)間幾乎無影響的前提下，高效完成對(duì)field過期判斷和刪除的功能。此類高級(jí)功能的合理使用能夠解放大量Redis的運(yùn)維、故障處理工作并降低業(yè)務(wù)的代碼復(fù)雜度，讓運(yùn)維將精力投入到其它更有價(jià)值的工作中，讓研發(fā)有更多的時(shí)間來寫更有價(jià)值的代碼。

2 熱Key的常見處理辦法

在Redis Cluster結(jié)構(gòu)中對(duì)熱Key進(jìn)行復(fù)制

在Redis Cluster中，熱Key由于遷移粒度問題造成請(qǐng)求無法打散使單一node的壓力無法下降。此時(shí)可以將對(duì)應(yīng)熱Key進(jìn)行復(fù)制并遷移至其他node，例如為熱Key foo復(fù)制出3個(gè)內(nèi)容完全一樣的Key并名為foo2，foo3，foo4，然后將這三個(gè)Key遷移到其他node來解決單一node的熱Key壓力。

該方案的缺點(diǎn)在于代碼需要聯(lián)動(dòng)修改，同時(shí)，Key一變多帶來了數(shù)據(jù)一致性挑戰(zhàn)：由更新一個(gè)Key演變?yōu)樾枰瑫r(shí)更新多個(gè)Key，在很多時(shí)候，該方案僅建議用來臨時(shí)解決當(dāng)前的棘手問題。

使用讀寫分離架構(gòu)

如果熱Key的產(chǎn)生來自于讀請(qǐng)求，那么讀寫分離是一個(gè)很好的解決方案。在使用讀寫分離架構(gòu)時(shí)可以通過不斷的增加從節(jié)點(diǎn)來降低每個(gè)Redis實(shí)例中的讀請(qǐng)求壓力。

然而，讀寫分離架構(gòu)在業(yè)務(wù)代碼復(fù)雜度增加的同時(shí)，同樣帶來了Redis集群架構(gòu)復(fù)雜度的增加：我們不僅要為多個(gè)從節(jié)點(diǎn)提供轉(zhuǎn)發(fā)層（如Proxy，LVS等）來實(shí)現(xiàn)負(fù)載均衡，還要考慮從節(jié)點(diǎn)數(shù)量顯著增加后帶來的故障率增加的問題，Redis集群架構(gòu)變更的同時(shí)為監(jiān)控、運(yùn)維、故障處理帶來了更大的挑戰(zhàn)。

但是，這一切在阿里云Redis服務(wù)中顯得極為簡(jiǎn)單，阿里云Redis服務(wù)以開箱即用的方式提供服務(wù)。同時(shí)，在業(yè)務(wù)的發(fā)展發(fā)生變化時(shí)，阿里云的Redis服務(wù)允許用戶通過變配的方式調(diào)整集群架構(gòu)來輕松應(yīng)對(duì)，如：主從轉(zhuǎn)變?yōu)樽x寫分離，讀寫分構(gòu)轉(zhuǎn)變?yōu)榧?，主從轉(zhuǎn)變?yōu)橹С肿x寫分離的集群，以及由社區(qū)版直接轉(zhuǎn)變?yōu)橹С执罅扛呒?jí)特性的企業(yè)版Redis（Tair）。

讀寫分離架構(gòu)同樣存在缺點(diǎn)，在請(qǐng)求量極大的場(chǎng)景下，讀寫分離架構(gòu)會(huì)產(chǎn)生不可避免的延遲，此時(shí)會(huì)有讀取到臟數(shù)據(jù)的問題，因此，在讀寫壓力都較大寫對(duì)數(shù)據(jù)一致性要求很高的場(chǎng)景下，讀寫分離架構(gòu)并不合適。

使用阿里云Tair的QueryCache特性

QueryCache是阿里云Tair（Redis企業(yè)版）服務(wù)的企業(yè)級(jí)特性之一，它的原理如下圖2-1：

圖2-1：Tair QueryCache原理

阿里云數(shù)據(jù)庫(kù)Redis會(huì)根據(jù)高效的排序和統(tǒng)計(jì)算法識(shí)別出實(shí)例中存在的熱點(diǎn)Key，開啟該功能后，Proxy點(diǎn)會(huì)根據(jù)設(shè)定的規(guī)則緩存熱點(diǎn)Key的請(qǐng)求和查詢結(jié)果（僅緩存熱點(diǎn)Key的查詢結(jié)果，無需緩存整個(gè)Key），當(dāng)在緩存有效時(shí)間內(nèi)收到相同的請(qǐng)求時(shí)Proxy會(huì)直接返回結(jié)果至客戶端，無需和后端的Redis分片執(zhí)行交互。在提升讀取速度的同時(shí)，降低了熱點(diǎn)Key對(duì)數(shù)據(jù)分片的性能影響，避免發(fā)生請(qǐng)求傾斜。

至此，來自客戶端的同樣的請(qǐng)求無需再與Proxy后端的Redis進(jìn)行交互而由Proxy直接返回?cái)?shù)據(jù)，指向熱Key的請(qǐng)求由一個(gè)Redis節(jié)點(diǎn)承擔(dān)轉(zhuǎn)為多個(gè)Proxy共同承擔(dān)，能夠大幅度降低Redis節(jié)點(diǎn)的熱Key壓力，同時(shí)Tair的QueryCache功能還提供了大量的命令來方便用戶查看、管理，如通過querycache keys命令查看所有被緩存熱Key，通過querycache listall獲取所有已緩存的所有命令等。

Tair QueryCache智能化的熱Key判定與緩存聯(lián)動(dòng)功同樣能夠降低運(yùn)維及研發(fā)的工作負(fù)擔(dān)。

與傳統(tǒng)的Redis同步中間件相比，阿里云Redis全球分布式緩存具有高可靠性、高吞吐低延遲、同步正確性高等特點(diǎn)。