您好,登錄后才能下訂單哦!
前言
Redis4.0新增了非常實用的lazy free特性,從根本上解決Big Key(主要指定元素較多集合類型Key)刪除的風(fēng)險。筆者在redis運維中也遇過幾次Big Key刪除帶來可用性和性能故障。
本文分為以下幾節(jié)說明redis lazy free:
lazy free的定義
lazy free可譯為惰性刪除或延遲釋放;當(dāng)刪除鍵的時候,redis提供異步延時釋放key內(nèi)存的功能,把key釋放操作放在bio(Background I/O)單獨的子線程處理中,減少刪除big key對redis主線程的阻塞。有效地避免刪除big key帶來的性能和可用性問題。
我們?yōu)槭裁葱枰猯azy free
Redis是single-thread程序(除少量的bio任務(wù)),當(dāng)運行一個耗時較大的請求時,會導(dǎo)致所有請求排隊等待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版本和負載等因素有關(guān)
Key類型 | Item數(shù)量 | 耗時 |
---|---|---|
Hash | ~100萬 | ~1000ms |
List | ~100萬 | ~1000ms |
Set | ~100萬 | ~1000ms |
Sorted Set | ~100萬 | ~1000ms |
在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é)點因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實現(xiàn)。
唯一不同時,UNLINK在刪除集合類鍵時,如果集合鍵的元素個數(shù)大于64個(詳細后文),會把真正的內(nèi)存釋放操作,給單獨的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異步清理選項,redis在清理整個實例或DB時,操作都是異步的。
127.0.0.1:7000> DBSIZE (integer) 1812295 127.0.0.1:7000> flushall //同步清理實例數(shù)據(jù),180萬個key耗時1020毫秒 OK (1.02s) 127.0.0.1:7000> DBSIZE (integer) 1812637 127.0.0.1:7000> flushall async //異步清理實例數(shù)據(jù),180萬個key耗時約9毫秒 OK 127.0.0.1:7000> SLOWLOG get 1) 1) (integer) 2996109 2) (integer) 1505465989 3) (integer) 9274 //指令運行耗時9.2毫秒 4) 1) "flushall" 2) "async" 5) "127.0.0.1:20110" 6) ""
被動刪除鍵使用lazy free
lazy free應(yīng)用于被動刪除中,目前有4種場景,每種場景對應(yīng)一個配置參數(shù); 默認都是關(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é)合實際情況,開啟被動刪除的
lazy free 觀察redis內(nèi)存使用情況。
lazyfree-lazy-eviction
針對redis內(nèi)存使用達到maxmeory,并設(shè)置有淘汰策略時;在被動淘汰鍵時,是否采用lazy free機制;
因為此場景開啟lazy free, 可能使用淘汰鍵的內(nèi)存釋放不及時,導(dǎo)致redis內(nèi)存超用,超過maxmemory的限制。此場景使用時,請結(jié)合業(yè)務(wù)測試。
lazyfree-lazy-expire --todo 驗證這類操作 同步到從庫的是DEL還是UNLINK.
針對設(shè)置有TTL的鍵,達到過期后,被redis清理刪除時是否采用lazy free機制;
此場景建議開啟,因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進行全量數(shù)據(jù)同步,slave在加載master的RDB文件前,會運行flushall來清理自己的數(shù)據(jù)場景,
參數(shù)設(shè)置決定是否采用異常flush機制。如果內(nèi)存變動不大,建議可開啟。可減少全量同步耗時,從而減少主庫因輸出緩沖區(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操作,在等待被實際回收內(nèi)容的鍵個數(shù)。并不能體現(xiàn)單個大鍵的元素個數(shù)或等待lazy free回收的內(nèi)存大小。
所以此值有一定參考值,可監(jiān)測redis lazy free的效率或堆積鍵數(shù)量; 比如在flushall async場景下會有少量的堆積。
lazy free實現(xiàn)的簡單分析
antirez為實現(xiàn)lazy free功能,對很多底層結(jié)構(gòu)和關(guān)鍵函數(shù)都做了修改;該小節(jié)只介紹lazy free的功能實現(xiàn)邏輯;代碼主要在源文件lazyfree.c和bio.c中。
UNLINK命令
unlink命令入口函數(shù)unlinkCommand()和del調(diào)用相同函數(shù)delGenericCommand()進行刪除KEY操作,使用lazy標(biāo)識是否為lazyfree調(diào)用。如果是lazyfree,則調(diào)用dbAsyncDelete()函數(shù)。
但并非每次unlink命令就一定啟用lazy free,redis會先判斷釋放KEY的代價(cost),當(dāng)cost大于LAZYFREE_THRESHOLD才進行l(wèi)azy free.
釋放key代價計算函數(shù)lazyfreeGetFreeEffort(),集合類型鍵,且滿足對應(yīng)編碼,cost就是集合鍵的元數(shù)個數(shù),否則cost就是1.
舉例:
所以可以看出,redis的lazy free的cost計算主要時間復(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,用于判斷是否進行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); //進行unlink處理,但不進行實際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子線程進行實際free操作,不通過主線程運行 atomicIncr(lazyfree_objects,1); //待處理的lazyfree對象個數(shù)加1,通過info命令可查看 bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL); dictSetVal(db->dict,de,NULL); } } }
在bio中實際調(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()來進行整個實例或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中實際調(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ù)處理邏輯實現(xiàn)。
總結(jié)
因為Redis是單個主線程處理,antirez一直強調(diào)"Lazy Redis is better Redis".
而lazy free的本質(zhì)就是把某些cost(主要時間復(fù)制度,占用主線程cpu時間片)較高刪除操作,從redis主線程剝離,讓bio子線程來處理,極大地減少主線阻塞時間。從而減少刪除導(dǎo)致性能和穩(wěn)定性問題。
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持億速云。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。