前言
成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),煙臺(tái)企業(yè)網(wǎng)站建設(shè),煙臺(tái)品牌網(wǎng)站建設(shè),網(wǎng)站定制,煙臺(tái)網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷(xiāo),網(wǎng)絡(luò)優(yōu)化,煙臺(tái)網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M(mǎn)足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專(zhuān)業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶(hù)成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
redis4.0新增了非常實(shí)用的lazy free特性，從根本上解決Big Key(主要指定元素較多集合類(lèi)型Key)刪除的風(fēng)險(xiǎn)。筆者在redis運(yùn)維中也遇過(guò)幾次Big Key刪除帶來(lái)可用性和性能故障。
本文分為以下幾節(jié)說(shuō)明redis lazy free：
lazy free的定義
lazy free可譯為惰性刪除或延遲釋放；當(dāng)刪除鍵的時(shí)候,redis提供異步延時(shí)釋放key內(nèi)存的功能，把key釋放操作放在bio(Background I/O)單獨(dú)的子線程處理中，減少刪除big key對(duì)redis主線程的阻塞。有效地避免刪除big key帶來(lái)的性能和可用性問(wèn)題。
我們?yōu)槭裁葱枰猯azy free
Redis是single-thread程序(除少量的bio任務(wù)),當(dāng)運(yùn)行一個(gè)耗時(shí)較大的請(qǐng)求時(shí)，會(huì)導(dǎo)致所有請(qǐng)求排隊(duì)等待redis不能響應(yīng)其他請(qǐng)求，引起性能問(wèn)題,甚至集群發(fā)生故障切換。
而redis刪除大的集合鍵時(shí)，就屬于這類(lèi)比較耗時(shí)的請(qǐng)求。通過(guò)測(cè)試來(lái)看，刪除一個(gè)100萬(wàn)個(gè)元素的集合鍵，耗時(shí)約1000ms左右。
以下測(cè)試，刪除一個(gè)100萬(wàn)個(gè)字段的hash鍵，耗時(shí)1360ms；處理此DEL請(qǐng)求期間，其他請(qǐng)求完全被阻塞。
刪除一個(gè)100萬(wàn)字段的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) “"
測(cè)試估算，可參考；和硬件環(huán)境、Redis版本和負(fù)載等因素有關(guān)
| Key類(lèi)型 | Item數(shù)量 | 耗時(shí) |
|---|---|---|
| Hash | ~100萬(wàn) | ~1000ms |
| List | ~100萬(wàn) | ~1000ms |
| Set | ~100萬(wàn) | ~1000ms |
| Sorted Set | ~100萬(wàn) | ~1000ms |
在redis4.0前，沒(méi)有l(wèi)azy free功能；DBA只能通過(guò)取巧的方法，類(lèi)似scan big key,每次刪除100個(gè)元素；但在面對(duì)“被動(dòng)”刪除鍵的場(chǎng)景，這種取巧的刪除就無(wú)能為力。
例如：我們生產(chǎn)Redis Cluster大集群，業(yè)務(wù)緩慢地寫(xiě)入一個(gè)帶有TTL的2000多萬(wàn)個(gè)字段的Hash鍵，當(dāng)這個(gè)鍵過(guò)期時(shí)，redis開(kāi)始被動(dòng)清理它時(shí)，導(dǎo)致redis被阻塞20多秒，當(dāng)前分片主節(jié)點(diǎn)因20多秒不能處理請(qǐng)求，并發(fā)生主庫(kù)故障切換。
redis4.0有l(wèi)azy free功能后，這類(lèi)主動(dòng)或被動(dòng)的刪除big key時(shí)，和一個(gè)O(1)指令的耗時(shí)一樣,亞毫秒級(jí)返回； 把真正釋放redis元素耗時(shí)動(dòng)作交由bio后臺(tái)任務(wù)執(zhí)行。
lazy free的使用
lazy free的使用分為2類(lèi)：第一類(lèi)是與DEL命令對(duì)應(yīng)的主動(dòng)刪除，第二類(lèi)是過(guò)期key刪除、maxmemory key驅(qū)逐淘汰刪除。
主動(dòng)刪除鍵使用lazy free
UNLINK命令
UNLINK命令是與DEL一樣刪除key功能的lazy free實(shí)現(xiàn)。
唯一不同時(shí)，UNLINK在刪除集合類(lèi)鍵時(shí)，如果集合鍵的元素個(gè)數(shù)大于64個(gè)(詳細(xì)后文），會(huì)把真正的內(nèi)存釋放操作，給單獨(dú)的bio來(lái)操作。
示例如下：使用UNLINK命令刪除一個(gè)大鍵mylist, 它包含200萬(wàn)個(gè)元素，但用時(shí)只有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
通過(guò)對(duì)FLUSHALL/FLUSHDB添加ASYNC異步清理選項(xiàng)，redis在清理整個(gè)實(shí)例或DB時(shí)，操作都是異步的。
127.0.0.1:7000> DBSIZE (integer) 1812295 127.0.0.1:7000> flushall //同步清理實(shí)例數(shù)據(jù)，180萬(wàn)個(gè)key耗時(shí)1020毫秒 OK (1.02s) 127.0.0.1:7000> DBSIZE (integer) 1812637 127.0.0.1:7000> flushall async //異步清理實(shí)例數(shù)據(jù)，180萬(wàn)個(gè)key耗時(shí)約9毫秒 OK 127.0.0.1:7000> SLOWLOG get 1) 1) (integer) 2996109 2) (integer) 1505465989 3) (integer) 9274 //指令運(yùn)行耗時(shí)9.2毫秒 4) 1) "flushall" 2) "async" 5) "127.0.0.1:20110" 6) ""
被動(dòng)刪除鍵使用lazy free
lazy free應(yīng)用于被動(dòng)刪除中，目前有4種場(chǎng)景，每種場(chǎng)景對(duì)應(yīng)一個(gè)配置參數(shù)； 默認(rèn)都是關(guān)閉。
lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no slave-lazy-flush no
注意：從測(cè)試來(lái)看lazy free回收內(nèi)存效率還是比較高的； 但在生產(chǎn)環(huán)境請(qǐng)結(jié)合實(shí)際情況，開(kāi)啟被動(dòng)刪除的
lazy free 觀察redis內(nèi)存使用情況。
lazyfree-lazy-eviction
針對(duì)redis內(nèi)存使用達(dá)到maxmeory，并設(shè)置有淘汰策略時(shí)；在被動(dòng)淘汰鍵時(shí)，是否采用lazy free機(jī)制；
因?yàn)榇藞?chǎng)景開(kāi)啟lazy free, 可能使用淘汰鍵的內(nèi)存釋放不及時(shí)，導(dǎo)致redis內(nèi)存超用，超過(guò)maxmemory的限制。此場(chǎng)景使用時(shí)，請(qǐng)結(jié)合業(yè)務(wù)測(cè)試。
lazyfree-lazy-expire --todo 驗(yàn)證這類(lèi)操作 同步到從庫(kù)的是DEL還是UNLINK.
針對(duì)設(shè)置有TTL的鍵，達(dá)到過(guò)期后，被redis清理刪除時(shí)是否采用lazy free機(jī)制；
此場(chǎng)景建議開(kāi)啟，因TTL本身是自適應(yīng)調(diào)整的速度。
lazyfree-lazy-server-del
針對(duì)有些指令在處理已存在的鍵時(shí)，會(huì)帶有一個(gè)隱式的DEL鍵的操作。如rename命令，當(dāng)目標(biāo)鍵已存在,redis會(huì)先刪除目標(biāo)鍵，如果這些目標(biāo)鍵是一個(gè)big key,那就會(huì)引入阻塞刪除的性能問(wèn)題。 此參數(shù)設(shè)置就是解決這類(lèi)問(wèn)題，建議可開(kāi)啟。
slave-lazy-flush
針對(duì)slave進(jìn)行全量數(shù)據(jù)同步，slave在加載master的RDB文件前，會(huì)運(yùn)行flushall來(lái)清理自己的數(shù)據(jù)場(chǎng)景，
參數(shù)設(shè)置決定是否采用異常flush機(jī)制。如果內(nèi)存變動(dòng)不大，建議可開(kāi)啟?？蓽p少全量同步耗時(shí)，從而減少主庫(kù)因輸出緩沖區(qū)爆漲引起的內(nèi)存使用增長(zhǎng)。
lazy free的監(jiān)控
lazy free能監(jiān)控的數(shù)據(jù)指標(biāo)，只有一個(gè)值：lazyfree_pending_objects，表示redis執(zhí)行l(wèi)azy free操作，在等待被實(shí)際回收內(nèi)容的鍵個(gè)數(shù)。并不能體現(xiàn)單個(gè)大鍵的元素個(gè)數(shù)或等待lazy free回收的內(nèi)存大小。
所以此值有一定參考值，可監(jiān)測(cè)redis lazy free的效率或堆積鍵數(shù)量； 比如在flushall async場(chǎng)景下會(huì)有少量的堆積。
lazy free實(shí)現(xiàn)的簡(jiǎn)單分析
antirez為實(shí)現(xiàn)lazy free功能，對(duì)很多底層結(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)識(shí)是否為lazyfree調(diào)用。如果是lazyfree,則調(diào)用dbAsyncDelete()函數(shù)。
但并非每次unlink命令就一定啟用lazy free，redis會(huì)先判斷釋放KEY的代價(jià)(cost),當(dāng)cost大于LAZYFREE_THRESHOLD才進(jìn)行l(wèi)azy free.
釋放key代價(jià)計(jì)算函數(shù)lazyfreeGetFreeEffort()，集合類(lèi)型鍵，且滿(mǎn)足對(duì)應(yīng)編碼，cost就是集合鍵的元數(shù)個(gè)數(shù)，否則cost就是1.
舉例：
所以可以看出，redis的lazy free的cost計(jì)算主要時(shí)間復(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一個(gè)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); //評(píng)估free當(dāng)前key的代價(jià)
/* 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操作，不通過(guò)主線程運(yùn)行
atomicIncr(lazyfree_objects,1); //待處理的lazyfree對(duì)象個(gè)數(shù)加1，通過(guò)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); //更新對(duì)應(yīng)引用，根據(jù)不同類(lèi)型，調(diào)用不同的free函數(shù)
atomicDecr(lazyfree_objects,1); //完成key的free,更新待處理lazyfree的鍵個(gè)數(shù)
}flushall/flushdb async命令
當(dāng)flushall/flushdb帶上async,函數(shù)emptyDb()調(diào)用emptyDbAsync()來(lái)進(jìn)行整個(gè)實(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的兩個(gè)hash tables暫存起來(lái)
db->dict = dictCreate(&dbDictType,NULL); //為db創(chuàng)建兩個(gè)空的hash tables
db->expires = dictCreate(&keyptrDictType,NULL);
atomicIncr(lazyfree_objects,dictSize(oldht1)); //更新待處理lazyfree的鍵個(gè)數(shù)，加上db的key個(gè)數(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);//完成整個(gè)DB的free,更新待處理lazyfree的鍵個(gè)數(shù)
}被動(dòng)刪除鍵使用lazy free
被動(dòng)刪除4個(gè)場(chǎng)景，redis在每個(gè)場(chǎng)景調(diào)用時(shí)，都會(huì)判斷對(duì)應(yīng)的參數(shù)是否開(kāi)啟，如果參數(shù)開(kāi)啟，則調(diào)用以上對(duì)應(yīng)的lazy free函數(shù)處理邏輯實(shí)現(xiàn)。
總結(jié)
因?yàn)镽edis是單個(gè)主線程處理，antirez一直強(qiáng)調(diào)"Lazy Redis is better Redis".
而lazy free的本質(zhì)就是把某些cost(主要時(shí)間復(fù)制度，占用主線程cpu時(shí)間片)較高刪除操作，從redis主線程剝離，讓bio子線程來(lái)處理，極大地減少主線阻塞時(shí)間。從而減少刪除導(dǎo)致性能和穩(wěn)定性問(wèn)題。
以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持創(chuàng)新互聯(lián)。
