前言

Redis4.0新增了非常實(shí)用的lazy free特性，從根本上解決Big Key(主要指定元素較多集合類型Key)刪除的風(fēng)險。筆者在redis運(yùn)維中也遇過幾次Big Key刪除帶來可用性和性能故障。

本文分為以下幾節(jié)說明redis lazy free：

• lazy free的定義
• 我們?yōu)槭裁葱枰猯azy free
• lazy free的使用
• lazy free的監(jiān)控
• lazy free實(shí)現(xiàn)的簡單分析

lazy free的定義

lazy free可譯為惰性刪除或延遲釋放；當(dāng)刪除鍵的時候,redis提供異步延時釋放key內(nèi)存的功能，把key釋放操作放在bio(Background I/O)單獨(dú)的子線程處理中，減少刪除big key對redis主線程的阻塞。有效地避免刪除big key帶來的性能和可用性問題。

我們?yōu)槭裁葱枰猯azy free

Redis是single-thread程序(除少量的bio任務(wù)),當(dāng)運(yùn)行一個耗時較大的請求時，會導(dǎo)致所有請求排隊(duì)等待redis不能響應(yīng)其他請求，引起性能問題,甚至集群發(fā)生故障切換。
而redis刪除大的集合鍵時，就屬于這類比較耗時的請求。通過測試來看，刪除一個100萬個元素的集合鍵，耗時約1000ms左右。

以下測試，刪除一個100萬個字段的hash鍵，耗時1360ms；處理此DEL請求期間，其他請求完全被阻塞。

刪除一個100萬字段的hash鍵
127.0.0.1:6379> HLEN hlazykey
(integer) 1000000
127.0.0.1:6379> del hlazykey
(integer) 1
(1.36s)
127.0.0.1:6379> SLOWLOG get
1) 1) (integer) 0
2) (integer) 1501314385
3) (integer) 1360908
4) 1) "del"
2) "hlazykey"
5) "127.0.0.1:35595"
6) “"

測試估算，可參考；和硬件環(huán)境、Redis版本和負(fù)載等因素有關(guān)

在redis4.0前，沒有l(wèi)azy free功能；DBA只能通過取巧的方法，類似scan big key,每次刪除100個元素；但在面對“被動”刪除鍵的場景，這種取巧的刪除就無能為力。

例如：我們生產(chǎn)Redis Cluster大集群，業(yè)務(wù)緩慢地寫入一個帶有TTL的2000多萬個字段的Hash鍵，當(dāng)這個鍵過期時，redis開始被動清理它時，導(dǎo)致redis被阻塞20多秒，當(dāng)前分片主節(jié)點(diǎn)因20多秒不能處理請求，并發(fā)生主庫故障切換。

redis4.0有l(wèi)azy free功能后，這類主動或被動的刪除big key時，和一個O(1)指令的耗時一樣,亞毫秒級返回； 把真正釋放redis元素耗時動作交由bio后臺任務(wù)執(zhí)行。

lazy free的使用

lazy free的使用分為2類：第一類是與DEL命令對應(yīng)的主動刪除，第二類是過期key刪除、maxmemory key驅(qū)逐淘汰刪除。

主動刪除鍵使用lazy free

UNLINK命令

UNLINK命令是與DEL一樣刪除key功能的lazy free實(shí)現(xiàn)。

唯一不同時，UNLINK在刪除集合類鍵時，如果集合鍵的元素個數(shù)大于64個(詳細(xì)后文），會把真正的內(nèi)存釋放操作，給單獨(dú)的bio來操作。

示例如下：使用UNLINK命令刪除一個大鍵mylist, 它包含200萬個元素，但用時只有0.03毫秒

127.0.0.1:7000> LLEN mylist
(integer) 2000000
127.0.0.1:7000> UNLINK mylist
(integer) 1
127.0.0.1:7000> SLOWLOG get
1) 1) (integer) 1
2) (integer) 1505465188
3) (integer) 30
4) 1) "UNLINK"
2) "mylist"
5) "127.0.0.1:17015"
6) ""

注意：DEL命令，還是并發(fā)阻塞的刪除操作

FLUSHALL/FLUSHDB ASYNC

通過對FLUSHALL/FLUSHDB添加ASYNC異步清理選項(xiàng)，redis在清理整個實(shí)例或DB時，操作都是異步的。

127.0.0.1:7000> DBSIZE
(integer) 1812295
127.0.0.1:7000> flushall //同步清理實(shí)例數(shù)據(jù)，180萬個key耗時1020毫秒
OK
(1.02s)
127.0.0.1:7000> DBSIZE
(integer) 1812637
127.0.0.1:7000> flushall async //異步清理實(shí)例數(shù)據(jù)，180萬個key耗時約9毫秒
OK
127.0.0.1:7000> SLOWLOG get
1) 1) (integer) 2996109
2) (integer) 1505465989
3) (integer) 9274 //指令運(yùn)行耗時9.2毫秒
4) 1) "flushall" 
2) "async"
5) "127.0.0.1:20110"
6) ""

被動刪除鍵使用lazy free

lazy free應(yīng)用于被動刪除中，目前有4種場景，每種場景對應(yīng)一個配置參數(shù)； 默認(rèn)都是關(guān)閉。

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no

注意：從測試來看lazy free回收內(nèi)存效率還是比較高的； 但在生產(chǎn)環(huán)境請結(jié)合實(shí)際情況，開啟被動刪除的

lazy free 觀察redis內(nèi)存使用情況。

lazyfree-lazy-eviction

針對redis內(nèi)存使用達(dá)到maxmeory，并設(shè)置有淘汰策略時；在被動淘汰鍵時，是否采用lazy free機(jī)制；
因?yàn)榇藞鼍伴_啟lazy free, 可能使用淘汰鍵的內(nèi)存釋放不及時，導(dǎo)致redis內(nèi)存超用，超過maxmemory的限制。此場景使用時，請結(jié)合業(yè)務(wù)測試。

lazyfree-lazy-expire --todo 驗(yàn)證這類操作 同步到從庫的是DEL還是UNLINK.

針對設(shè)置有TTL的鍵，達(dá)到過期后，被redis清理刪除時是否采用lazy free機(jī)制；
此場景建議開啟，因TTL本身是自適應(yīng)調(diào)整的速度。

lazyfree-lazy-server-del

針對有些指令在處理已存在的鍵時，會帶有一個隱式的DEL鍵的操作。如rename命令，當(dāng)目標(biāo)鍵已存在,redis會先刪除目標(biāo)鍵，如果這些目標(biāo)鍵是一個big key,那就會引入阻塞刪除的性能問題。 此參數(shù)設(shè)置就是解決這類問題，建議可開啟。

slave-lazy-flush

針對slave進(jìn)行全量數(shù)據(jù)同步，slave在加載master的RDB文件前，會運(yùn)行flushall來清理自己的數(shù)據(jù)場景，
參數(shù)設(shè)置決定是否采用異常flush機(jī)制。如果內(nèi)存變動不大，建議可開啟?？蓽p少全量同步耗時，從而減少主庫因輸出緩沖區(qū)爆漲引起的內(nèi)存使用增長。

lazy free的監(jiān)控

lazy free能監(jiān)控的數(shù)據(jù)指標(biāo)，只有一個值：lazyfree_pending_objects，表示redis執(zhí)行l(wèi)azy free操作，在等待被實(shí)際回收內(nèi)容的鍵個數(shù)。并不能體現(xiàn)單個大鍵的元素個數(shù)或等待lazy free回收的內(nèi)存大小。

所以此值有一定參考值，可監(jiān)測redis lazy free的效率或堆積鍵數(shù)量； 比如在flushall async場景下會有少量的堆積。

lazy free實(shí)現(xiàn)的簡單分析

antirez為實(shí)現(xiàn)lazy free功能，對很多底層結(jié)構(gòu)和關(guān)鍵函數(shù)都做了修改；該小節(jié)只介紹lazy free的功能實(shí)現(xiàn)邏輯；代碼主要在源文件lazyfree.c和bio.c中。

UNLINK命令

unlink命令入口函數(shù)unlinkCommand()和del調(diào)用相同函數(shù)delGenericCommand()進(jìn)行刪除KEY操作，使用lazy標(biāo)識是否為lazyfree調(diào)用。如果是lazyfree,則調(diào)用dbAsyncDelete()函數(shù)。

但并非每次unlink命令就一定啟用lazy free，redis會先判斷釋放KEY的代價(cost),當(dāng)cost大于LAZYFREE_THRESHOLD才進(jìn)行l(wèi)azy free.

釋放key代價計(jì)算函數(shù)lazyfreeGetFreeEffort()，集合類型鍵，且滿足對應(yīng)編碼，cost就是集合鍵的元數(shù)個數(shù)，否則cost就是1.
舉例：

• 一個包含100元素的list key, 它的free cost就是100
• 一個512MB的string key, 它的free cost是1

所以可以看出，redis的lazy free的cost計(jì)算主要時間復(fù)雜度相關(guān)。

lazyfreeGetFreeEffort()函數(shù)代碼

size_t lazyfreeGetFreeEffort(robj *obj) {
if (obj->type == OBJ_LIST) { 
quicklist *ql = obj->ptr;
return ql->len;
} else if (obj->type == OBJ_SET && obj->encoding == OBJ_ENCODING_HT) {
dict *ht = obj->ptr;
return dictSize(ht);
} else if (obj->type == OBJ_ZSET && obj->encoding == OBJ_ENCODING_SKIPLIST){
zset *zs = obj->ptr;
return zs->zsl->length;
} else if (obj->type == OBJ_HASH && obj->encoding == OBJ_ENCODING_HT) {
dict *ht = obj->ptr;
return dictSize(ht);
} else {
return 1; /* Everything else is a single allocation. */
}
}

dbAsyncDelete()函數(shù)的部分代碼

#define LAZYFREE_THRESHOLD 64 //根據(jù)FREE一個key的cost是否大于64，用于判斷是否進(jìn)行l(wèi)azy free調(diào)用
int dbAsyncDelete(redisDb *db, robj *key) {
/* Deleting an entry from the expires dict will not free the sds of
* the key, because it is shared with the main dictionary. */
if (dictSize(db->expires) > 0) dictDelete(db->expires,key->ptr); //從expires中直接刪除key
dictEntry *de = dictUnlink(db->dict,key->ptr); //進(jìn)行unlink處理，但不進(jìn)行實(shí)際free操作
if (de) {
robj *val = dictGetVal(de);
size_t free_effort = lazyfreeGetFreeEffort(val); //評估free當(dāng)前key的代價
/* If releasing the object is too much work, let's put it into the
* lazy free list. */
if (free_effort > LAZYFREE_THRESHOLD) { //如果free當(dāng)前key cost>64, 則把它放在lazy free的list, 使用bio子線程進(jìn)行實(shí)際free操作，不通過主線程運(yùn)行
atomicIncr(lazyfree_objects,1); //待處理的lazyfree對象個數(shù)加1，通過info命令可查看
bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL); 
dictSetVal(db->dict,de,NULL);
}
}
}

在bio中實(shí)際調(diào)用lazyfreeFreeObjectFromBioThread()函數(shù)釋放key

void lazyfreeFreeObjectFromBioThread(robj *o) {
decrRefCount(o); //更新對應(yīng)引用，根據(jù)不同類型，調(diào)用不同的free函數(shù)
atomicDecr(lazyfree_objects,1); //完成key的free,更新待處理lazyfree的鍵個數(shù)
}

flushall/flushdb async命令

當(dāng)flushall/flushdb帶上async,函數(shù)emptyDb()調(diào)用emptyDbAsync()來進(jìn)行整個實(shí)例或DB的lazy free邏輯處理。
emptyDbAsync處理邏輯如下：

/* Empty a Redis DB asynchronously. What the function does actually is to
* create a new empty set of hash tables and scheduling the old ones for
* lazy freeing. */
void emptyDbAsync(redisDb *db) {
dict *oldht1 = db->dict, *oldht2 = db->expires; //把db的兩個hash tables暫存起來
db->dict = dictCreate(&dbDictType,NULL); //為db創(chuàng)建兩個空的hash tables
db->expires = dictCreate(&keyptrDictType,NULL);
atomicIncr(lazyfree_objects,dictSize(oldht1)); //更新待處理lazyfree的鍵個數(shù)，加上db的key個數(shù)
bioCreateBackgroundJob(BIO_LAZY_FREE,NULL,oldht1,oldht2);//加入到bio list
}

在bio中實(shí)際調(diào)用lazyfreeFreeDatabaseFromBioThread函數(shù)釋放db

void lazyfreeFreeDatabaseFromBioThread(dict *ht1, dict *ht2) {
size_t numkeys = dictSize(ht1);
dictRelease(ht1);
dictRelease(ht2);
atomicDecr(lazyfree_objects,numkeys);//完成整個DB的free,更新待處理lazyfree的鍵個數(shù) 
}

被動刪除鍵使用lazy free

被動刪除4個場景，redis在每個場景調(diào)用時，都會判斷對應(yīng)的參數(shù)是否開啟，如果參數(shù)開啟，則調(diào)用以上對應(yīng)的lazy free函數(shù)處理邏輯實(shí)現(xiàn)。

總結(jié)

因?yàn)镽edis是單個主線程處理，antirez一直強(qiáng)調(diào)"Lazy Redis is better Redis".

而lazy free的本質(zhì)就是把某些cost(主要時間復(fù)制度，占用主線程cpu時間片)較高刪除操作，從redis主線程剝離，讓bio子線程來處理，極大地減少主線阻塞時間。從而減少刪除導(dǎo)致性能和穩(wěn)定性問題。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。