Redis大key的一些場景及問題
大key場景
Redis使用者應該都遇到過大key相關的場景，比如：
1、熱門話題下評論、答案排序場景。
2、大V的粉絲列表。
3、使用不恰當，或者對業務預估不準確、不及時進行處理垃圾數據等。
大key問題
由于Redis主線程為單線程模型，大key也會帶來一些問題，如：
1、集群模式在slot分片均勻情況下，會出現數據和查詢傾斜情況，部分有大key的Redis節點占用內存多，QPS高。
2、大key相關的刪除或者自動過期時，會出現qps突降或者突升的情況，極端情況下，會造成主從復制異常，Redis服務阻塞無法響應請求。大key的體積與刪除耗時可參考下表：
key類型 field數量耗時
Hash100萬1000ms
List100萬1000ms
Set100萬1000ms
Sorted Set100萬1000ms
Redis 4.0之前的大key的發現與刪除方法
1、redis-rdb-tools工具。redis實例上執行bgsave，然后對dump出來的rdb文件進行分析，找到其中的大KEY。
2、redis-cli --bigkeys命令。可以找到某個實例5種數據類型(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,
可以看到輸出的信息包括數據類型，key、內存大小、編碼類型等。Rdb工具優點在于獲取的key信息詳細、可選參數多、支持定制化需求，結果信息可選擇json或csv格式，后續處理方便，其缺點是需要離線操作，獲取結果時間較長。
redis-cli --bigkeys命令
Redis-cli --bigkeys是redis-cli自帶的一個命令。它對整個redis進行掃描，尋找較大的key，并打印統計結果。
例如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部分給出了每種數據結構中最大的Key以及統計信息。
redis-cli --bigkeys的優點是可以在線掃描，不阻塞服務；缺點是信息較少，內容不夠精確。掃描結果中只有string類型是以字節長度為衡量標準的。List、set、zset等都是以元素個數作為衡量標準，元素個數多不能說明占用內存就一定多。
自定義Python掃描腳本
通過strlen、hlen、scard等命令獲取字節大小或者元素個數,掃描結果比redis-cli --keys更精細，但是缺點和redis-cli --keys一樣，不贅述。
總之，之前的方法要么是用時較長離線解析，或者是不夠詳細的抽樣掃描，離理想的以內存為維度的在線掃描獲取詳細信息有一定距離。由于在redis4.0前,沒有lazy free機制;針對掃描出來的大key，DBA只能通過hscan、sscan、zscan方式漸進刪除若干個元素;但面對過期刪除鍵的場景,這種取巧的刪除就無能為力。我們只能祈禱自動清理過期key剛好在系統低峰時，降低對業務的影響。
Redis 4.0之后的大key的發現與刪除方法
Redis 4.0引入了memory usage命令和lazyfree機制，不管是對大key的發現，還是解決大key刪除或者過期造成的阻塞問題都有明顯的提升。
下面我們從源碼（摘自Redis 5.0.4版本）來理解memory usage和lazyfree的特點。
memory usage
{"memory",memoryCommand,-2,"rR",0,NULL,0,0,0,0,0}(server.c285?)void memoryCommand(client c) {/...//計算key大小是通過抽樣部分field來估算總大小。/elseif(!strcasecmp(c->argv[1]->ptr,"usage") &&c->argc >=3) { size_t usage = objectComputeSize(dictGetVal(de),samples);/...*/ }}(object.c1299?)
從上述源碼看到memory usage是通過調用objectComputeSize來計算key的大小。我們來看objectComputeSize函數的邏輯。
defineOBJ_COMPUTE_SIZE_DEF_SAMPLES 5 /* Default sample size. /size_tobjectComputeSize(robj o, size_t sample_size){/...代碼對數據類型進行了分類，此處只取hash類型說明//...//循環抽樣個field，累加獲取抽樣樣本內存值，默認抽樣樣本為5/while((de = dictNext(di)) != NULL && samples < sample_size) { ele = dictGetKey(de); ele2 = dictGetVal(de); elesize += sdsAllocSize(ele) + sdsAllocSize(ele2);elesize +=sizeof(structdictEntry); samples++; } dictReleaseIterator(di);/根據上一步計算的抽樣樣本內存值除以樣本量，再乘以總的filed個數計算總內存值/if(samples) asize += (double)elesize/samplesdictSize(d);/...*/ }(object.c779?)
由此，我們發現memory usage默認抽樣5個field來循環累加計算整個key的內存大小，樣本的數量決定了key的內存大小的準確性和計算成本，樣本越大，循環次數越多，計算結果更精確，性能消耗也越多。
我們可以通過Python腳本在集群低峰時掃描Redis，用較小的代價去獲取所有key的內存大小。以下為部分偽代碼，可根據實際情況設置大key閾值進行預警。
forkeyinr.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通常理解為單線程內存數據庫, 其實不然。Redis將最主要的網絡收發和執行命令等操作都放在了主工作線程，然而除此之外還有幾個bio后臺線程，從源碼中可以看到有處理關閉文件和刷盤的后臺線程，以及Redis4.0新增加的lazyfree線程。
/* Background job opcodes /#defineBIO_LAZY_FREE 2/ Deferred objects freeing. */(bio.h38?)
下面我們以unlink命令為例，來理解lazyfree的實現原理。
{"unlink",unlinkCommand,-2,"wF",0,NULL,1,-1,1,0,0},(server.c137?)void unlinkCommand(client *c) {delGenericCommand(c,1);}(db.c490?)
通過這幾段源碼可以看出del命令和unlink命令都是調用delGenericCommand，唯一的差別在于第二個參數不一樣。這個參數就是異步刪除參數。
/* This command implements DEL and LAZYDEL. /void delGenericCommand(client c, intlazy) {/.../int deleted =lazy? dbAsyncDelete(c->db,c->argv[j]) :dbSyncDelete(c->db,c->argv[j]);/.../}(db.c468?)
可以看到delGenericCommand函數根據lazy參數來決定是同步刪除還是異步刪除。當執行unlink命令時，傳入lazy參數值1，調用異步刪除函數dbAsyncDelete。否則執行del命令傳入參數值0，調用同步刪除函數dbSyncDelete。我們重點來看異步刪除dbAsyncDelete的實現邏輯：
defineLAZYFREE_THRESHOLD 64/定義后臺刪除的閾值,key的元素大于該閾值時才真正丟給后臺線程去刪除/intdbAsyncDelete(redisDb db, robj key){/...//lazyfreeGetFreeEffort來獲取val對象所包含的元素個數/size_tfree_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.c53?)
上面提到了當刪除key滿足閾值條件時，會將key放入BIO_LAZY_FREE后臺線程任務隊列。接下來我們來看BIO_LAZY_FREE后臺線程。
/.../elseif(type == BIO_LAZY_FREE) {if(job->arg1)/* 后臺刪除對象函數，調用decrRefCount減少key的引用計數，引用計數為0時會真正的釋放資源 / lazyfreeFreeObjectFromBioThread(job->arg1);elseif(job->arg2 && job->arg3)/ 后臺清空數據庫字典，調用dictRelease循環遍歷數據庫字典刪除所有key / lazyfreeFreeDatabaseFromBioThread(job->arg2,job->arg3);elseif(job->arg3)/ 后臺刪除key-slots映射表，在Redis集群模式下會用*/ lazyfreeFreeSlotsMapFromBioThread(job->arg3);}(bio.c197?)
unlink命令的邏輯可以總結為：執行unlink調用delGenericCommand函數傳入lazy參數值1，來調用異步刪除函數dbAsyncDelete，將滿足閾值的大key放入BIO_LAZY_FREE后臺線程任務隊列進行異步刪除。類似的后臺刪除命令還有flushdb async、flushall async。它們的原理都是獲取刪除標識進行判斷，然后調用異步刪除函數emptyDbAsnyc來清空數據庫。這些命令具體的實現邏輯可自行查看flushdbCommand部分源碼，在此不做贅述。
除了主動的大key刪除和數據庫清空操作外，過期key驅逐引發的刪除操作也會阻塞Redis服務。因此Redis4.0除了增加上述三個后臺刪除的命令外，還增加了4個后臺刪除配置項，分別為slave-lazy-flush、lazyfree-lazy-eviction、lazyfree-lazy-expire和lazyfree-lazy-server-del。
slave-lazy-flush：slave接收完RDB文件后清空數據選項。建議大家開啟slave-lazy-flush，這樣可減少slave節點flush操作時間，從而降低主從全量同步耗時的可能性。
lazyfree-lazy-eviction：內存用滿逐出選項。若開啟此選項可能導致淘汰key的內存釋放不夠及時，內存超用。
lazyfree-lazy-expire：過期key刪除選項。建議開啟。
lazyfree-lazy-server-del：內部刪除選項，比如rename命令將oldkey修改為一個已存在的newkey時，會先將newkey刪除掉。如果newkey是一個大key,可能會引起阻塞刪除。建議開啟。
上述四個后臺刪除相關的參數實現邏輯差異不大，都是通過參數選項進行判斷，從而選擇是否采用dbAsyncDelete或者emptyDbAsync進行異步刪除。
總結
在某些業務場景下，Redis大key的問題是難以避免的，但是，memory usage命令和lazyfree機制分別提供了內存維度的抽樣算法和異步刪除優化功能，這些特性有助于我們在實際業務中更好的預防大key的產生和解決大key造成的阻塞。關于Redis內核的優化思路也可從Redis作者Antirez的博客中窺測一二，他提出"Lazy Redis is better Redis"、"Slow commands threading"(允許在不同的線程中執行慢操作命令)，異步化應該是Redis優化的主要方向。
Redis作為個推消息推送的一項重要的基礎服務，性能的好壞至關重要。個推將Redis版本從2.8升級到5.0后，有效地解決了部分大key刪除或過期造成的阻塞問題。未來，個推將會持續關注Redis 5.0及后續的Redis 6.0，與大家共同探討如何更好地使用Redis。
參考文檔:
作者：個推大數據
鏈接：http://www.lxweimin.com/p/50c0894c0a19
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
