學會這幾個技巧，讓Redis大key問題遠離你

個推作為國內第三方推送市場的早期進入者，專注于為開發(fā)者提供高效穩(wěn)定的推送服務，經(jīng)過9年的積累和發(fā)展，服務了包括新浪、滴滴在內的數(shù)十萬APP。由于我們推送業(yè)務對并發(fā)量、速度要求很高，為此，我們選擇了高性能的內存數(shù)據(jù)庫Redis。然而，在實際業(yè)務場景中我們也遇到了一些Redis大key造成的服務阻塞問題，因此積累了一些應對經(jīng)驗。本文將對大key的發(fā)現(xiàn)、解決大key刪除造成的阻塞做相應的介紹。

Redis大key的一些場景及問題

大key場景

Redis使用者應該都遇到過大key相關的場景，比如：
1、熱門話題下評論、答案排序場景。
2、大V的粉絲列表。
3、使用不恰當，或者對業(yè)務預估不準確、不及時進行處理垃圾數(shù)據(jù)等。

大key問題

由于Redis主線程為單線程模型，大key也會帶來一些問題，如：
1、集群模式在slot分片均勻情況下，會出現(xiàn)數(shù)據(jù)和查詢傾斜情況，部分有大key的Redis節(jié)點占用內存多，QPS高。

2、大key相關的刪除或者自動過期時，會出現(xiàn)qps突降或者突升的情況，極端情況下，會造成主從復制異常，Redis服務阻塞無法響應請求。大key的體積與刪除耗時可參考下表：

key類型
field數(shù)量
耗時
Hash
~100萬
~1000ms
List
~100萬
~1000ms
Set
~100萬
~1000ms
Sorted Set
~100萬
~1000ms

Redis 4.0之前的大key的發(fā)現(xiàn)與刪除方法
1、redis-rdb-tools工具。redis實例上執(zhí)行bgsave，然后對dump出來的rdb文件進行分析，找到其中的大KEY。
2、redis-cli --bigkeys命令。可以找到某個實例5種數(shù)據(jù)類型(String、hash、list、set、zset)的最大key。
3、自定義的掃描腳本，以Python腳本居多，方法與redis-cli --bigkeys類似。
4、debug object key命令?？梢圆榭茨硞€key序列化后的長度，每次只能查找單個key的信息。官方不推薦。

redis-rdb-tools工具

關于rdb工具的詳細介紹請查看鏈接https://github.com/sripathikrishnan/redis-rdb-tools，在此只介紹內存相關的使用方法。基本的命令為 rdb -c memory dump.rdb (其中dump.rdb為Redis實例的rdb文件，可通過bgsave生成)。

輸出結果如下：
database,type,key,size_in_bytes,encoding,num_elements,len_largest_element
0,hash,hello1,1050,ziplist,86,22,
0,hash,hello2,2517,ziplist,222,8,
0,hash,hello3,2523,ziplist,156,12,
0,hash,hello4,62020,hashtable,776,32,
0,hash,hello5,71420,hashtable,1168,12,

可以看到輸出的信息包括數(shù)據(jù)類型，key、內存大小、編碼類型等。Rdb工具優(yōu)點在于獲取的key信息詳細、可選參數(shù)多、支持定制化需求，結果信息可選擇json或csv格式，后續(xù)處理方便，其缺點是需要離線操作，獲取結果時間較長。

redis-cli --bigkeys命令

Redis-cli --bigkeys是redis-cli自帶的一個命令。它對整個redis進行掃描，尋找較大的key，并打印統(tǒng)計結果。

例如redis-cli -p 6379 --bigkeys
#Scanning the entire keyspace to find biggest keys as well as
#average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
#per 100 SCAN commands (not usually needed).

[00.72%] Biggest hash found so far 'hello6' with 43 fields
[02.81%] Biggest string found so far 'hello7' with 31 bytes
[05.15%] Biggest string found so far 'hello8' with 32 bytes
[26.94%] Biggest hash found so far 'hello9' with 1795 fields
[32.00%] Biggest hash found so far 'hello10' with 4671 fields
[35.55%] Biggest string found so far 'hello11' with 36 bytes

-------- summary -------

Sampled 293070 keys in the keyspace!
Total key length in bytes is 8731143 (avg len 29.79)

Biggest string found 'hello11' has 36 bytes
Biggest hash found 'hello10' has 4671 fields

238027 strings with 2300436 bytes (81.22% of keys, avg size 9.66)
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
55043 hashs with 289965 fields (18.78% of keys, avg size 5.27)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

我們可以看到打印結果分為兩部分，掃描過程部分，只顯示了掃描到當前階段里最大的key。summary部分給出了每種數(shù)據(jù)結構中最大的Key以及統(tǒng)計信息。

redis-cli --bigkeys的優(yōu)點是可以在線掃描，不阻塞服務；缺點是信息較少，內容不夠精確。掃描結果中只有string類型是以字節(jié)長度為衡量標準的。List、set、zset等都是以元素個數(shù)作為衡量標準，元素個數(shù)多不能說明占用內存就一定多。

自定義Python掃描腳本

通過strlen、hlen、scard等命令獲取字節(jié)大小或者元素個數(shù),掃描結果比redis-cli --keys更精細，但是缺點和redis-cli --keys一樣，不贅述。

總之，之前的方法要么是用時較長離線解析，或者是不夠詳細的抽樣掃描，離理想的以內存為維度的在線掃描獲取詳細信息有一定距離。由于在redis4.0前,沒有l(wèi)azy free機制;針對掃描出來的大key，DBA只能通過hscan、sscan、zscan方式漸進刪除若干個元素;但面對過期刪除鍵的場景,這種取巧的刪除就無能為力。我們只能祈禱自動清理過期key剛好在系統(tǒng)低峰時，降低對業(yè)務的影響。

Redis 4.0之后的大key的發(fā)現(xiàn)與刪除方法
Redis 4.0引入了memory usage命令和lazyfree機制，不管是對大key的發(fā)現(xiàn)，還是解決大key刪除或者過期造成的阻塞問題都有明顯的提升。

下面我們從源碼（摘自Redis 5.0.4版本）來理解memory usage和lazyfree的特點。

memory usage

{"memory",memoryCommand,-2,"rR",0,NULL,0,0,0,0,0}
(server.c 285?)

void memoryCommand(client c) {
/.../
/計算key大小是通過抽樣部分field來估算總大小。/
else if (!strcasecmp(c->argv[1]->ptr,"usage") && c->argc >= 3) {
size_t usage = objectComputeSize(dictGetVal(de),samples);
/...*/
}
}
(object.c 1299?)

從上述源碼看到memory usage是通過調用objectComputeSize來計算key的大小。我們來看objectComputeSize函數(shù)的邏輯。

#define OBJ_COMPUTE_SIZE_DEF_SAMPLES 5 / Default sample size. /
size_t objectComputeSize(robj o, size_t sample_size) {
/...代碼對數(shù)據(jù)類型進行了分類，此處只取hash類型說明/
/.../
/循環(huán)抽樣個field，累加獲取抽樣樣本內存值，默認抽樣樣本為5/
while((de = dictNext(di)) != NULL && samples < sample_size) {
ele = dictGetKey(de);
ele2 = dictGetVal(de);
elesize += sdsAllocSize(ele) + sdsAllocSize(ele2);
elesize += sizeof(struct dictEntry);
samples++;
}
dictReleaseIterator(di);
/根據(jù)上一步計算的抽樣樣本內存值除以樣本量，再乘以總的filed個數(shù)計算總內存值/
if (samples) asize += (double)elesize/samplesdictSize(d);
/.../
}
(object.c 779?)

由此，我們發(fā)現(xiàn)memory usage默認抽樣5個field來循環(huán)累加計算整個key的內存大小，樣本的數(shù)量決定了key的內存大小的準確性和計算成本，樣本越大，循環(huán)次數(shù)越多，計算結果更精確，性能消耗也越多。

我們可以通過Python腳本在集群低峰時掃描Redis，用較小的代價去獲取所有key的內存大小。以下為部分偽代碼，可根據(jù)實際情況設置大key閾值進行預警。

for key in r.scan_iter(count=1000):
redis-cli = '/usr/bin/redis-cli'
configcmd = '%s -h %s -p %s memory usage %s' % (redis-cli, rip,rport,key)
keymemory = commands.getoutput(configcmd)

lazyfree機制

Lazyfree的原理是在刪除的時候只進行邏輯刪除，把key釋放操作放在bio(Background I/O)單獨的子線程處理中，減少刪除大key對redis主線程的阻塞，有效地避免因刪除大key帶來的性能問題。在此提一下bio線程，很多人把Redis通常理解為單線程內存數(shù)據(jù)庫, 其實不然。Redis將最主要的網(wǎng)絡收發(fā)和執(zhí)行命令等操作都放在了主工作線程，然而除此之外還有幾個bio后臺線程，從源碼中可以看到有處理關閉文件和刷盤的后臺線程，以及Redis4.0新增加的lazyfree線程。

/ Background job opcodes /
#define BIO_LAZY_FREE 2 / Deferred objects freeing. /
(bio.h 38?)

下面我們以unlink命令為例，來理解lazyfree的實現(xiàn)原理。

{"unlink",unlinkCommand,-2,"wF",0,NULL,1,-1,1,0,0},
(server.c 137?)

void unlinkCommand(client *c) {
delGenericCommand(c,1);
}
(db.c 490?)

通過這幾段源碼可以看出del命令和unlink命令都是調用delGenericCommand，唯一的差別在于第二個參數(shù)不一樣。這個參數(shù)就是異步刪除參數(shù)。

/ This command implements DEL and LAZYDEL. /
void delGenericCommand(client c, int lazy) {
/.../
int deleted = lazy ? dbAsyncDelete(c->db,c->argv[j]) :
dbSyncDelete(c->db,c->argv[j]);
/...*/
}
(db.c 468?)

可以看到delGenericCommand函數(shù)根據(jù)lazy參數(shù)來決定是同步刪除還是異步刪除。當執(zhí)行unlink命令時，傳入lazy參數(shù)值1，調用異步刪除函數(shù)dbAsyncDelete。否則執(zhí)行del命令傳入?yún)?shù)值0，調用同步刪除函數(shù)dbSyncDelete。我們重點來看異步刪除dbAsyncDelete的實現(xiàn)邏輯：

#define LAZYFREE_THRESHOLD 64
/定義后臺刪除的閾值,key的元素大于該閾值時才真正丟給后臺線程去刪除/
int dbAsyncDelete(redisDb db, robj key) {
/.../
/lazyfreeGetFreeEffort來獲取val對象所包含的元素個數(shù)/
size_t free_effort = lazyfreeGetFreeEffort(val);

    /* 對刪除key進行判斷，滿足閾值條件時進行后臺刪除 */
    if (free_effort > LAZYFREE_THRESHOLD && val->refcount == 1) {
        atomicIncr(lazyfree_objects,1);
        bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL);
        /*將刪除對象放入BIO_LAZY_FREE后臺線程任務隊列*/
        dictSetVal(db->dict,de,NULL);
        /*將第一步獲取到的val值設置為null*/
    }
/*...*/

}
(lazyfree.c 53?)

上面提到了當刪除key滿足閾值條件時，會將key放入BIO_LAZY_FREE后臺線程任務隊列。接下來我們來看BIO_LAZY_FREE后臺線程。

/.../
else if (type == BIO_LAZY_FREE) {
if (job->arg1)
/ 后臺刪除對象函數(shù)，調用decrRefCount減少key的引用計數(shù)，引用計數(shù)為0時會真正的釋放資源 /
lazyfreeFreeObjectFromBioThread(job->arg1);
else if (job->arg2 && job->arg3)
/ 后臺清空數(shù)據(jù)庫字典，調用dictRelease循環(huán)遍歷數(shù)據(jù)庫字典刪除所有key /
lazyfreeFreeDatabaseFromBioThread(job->arg2,job->arg3);
else if (job->arg3)
/ 后臺刪除key-slots映射表，在Redis集群模式下會用/
lazyfreeFreeSlotsMapFromBioThread(job->arg3);
}
(bio.c 197?)

unlink命令的邏輯可以總結為：執(zhí)行unlink調用delGenericCommand函數(shù)傳入lazy參數(shù)值1，來調用異步刪除函數(shù)dbAsyncDelete，將滿足閾值的大key放入BIO_LAZY_FREE后臺線程任務隊列進行異步刪除。類似的后臺刪除命令還有flushdb async、flushall async。它們的原理都是獲取刪除標識進行判斷，然后調用異步刪除函數(shù)emptyDbAsnyc來清空數(shù)據(jù)庫。這些命令具體的實現(xiàn)邏輯可自行查看flushdbCommand部分源碼，在此不做贅述。

除了主動的大key刪除和數(shù)據(jù)庫清空操作外，過期key驅逐引發(fā)的刪除操作也會阻塞Redis服務。因此Redis4.0除了增加上述三個后臺刪除的命令外，還增加了4個后臺刪除配置項，分別為slave-lazy-flush、lazyfree-lazy-eviction、lazyfree-lazy-expire和lazyfree-lazy-server-del。

slave-lazy-flush：slave接收完RDB文件后清空數(shù)據(jù)選項。建議大家開啟slave-lazy-flush，這樣可減少slave節(jié)點flush操作時間，從而降低主從全量同步耗時的可能性。
lazyfree-lazy-eviction：內存用滿逐出選項。若開啟此選項可能導致淘汰key的內存釋放不夠及時，內存超用。
lazyfree-lazy-expire：過期key刪除選項。建議開啟。
lazyfree-lazy-server-del：內部刪除選項，比如rename命令將oldkey修改為一個已存在的newkey時，會先將newkey刪除掉。如果newkey是一個大key,可能會引起阻塞刪除。建議開啟。

上述四個后臺刪除相關的參數(shù)實現(xiàn)邏輯差異不大，都是通過參數(shù)選項進行判斷，從而選擇是否采用dbAsyncDelete或者emptyDbAsync進行異步刪除。

總結
在某些業(yè)務場景下，Redis大key的問題是難以避免的，但是，memory usage命令和lazyfree機制分別提供了內存維度的抽樣算法和異步刪除優(yōu)化功能，這些特性有助于我們在實際業(yè)務中更好的預防大key的產(chǎn)生和解決大key造成的阻塞。關于Redis內核的優(yōu)化思路也可從Redis作者Antirez的博客中窺測一二，他提出"Lazy Redis is better Redis"、"Slow commands threading"(允許在不同的線程中執(zhí)行慢操作命令)，異步化應該是Redis優(yōu)化的主要方向。

Redis作為個推消息推送的一項重要的基礎服務，性能的好壞至關重要。個推將Redis版本從2.8升級到5.0后，有效地解決了部分大key刪除或過期造成的阻塞問題。未來，個推將會持續(xù)關注Redis 5.0及后續(xù)的Redis 6.0，與大家共同探討如何更好地使用Redis。

參考文檔:
1、http://antirez.com/news/93
2、http://antirez.com/news/126