Redis的新特性懶惰刪除Lazy Free詳解

這篇文章主要介紹了Redis的新特性懶惰刪除Lazy Free詳解,Redis4.0新增了非常實用的lazy free特性，從根本上解決Big Key(主要指定元素較多集合類型Key)刪除的風險,需要的朋友可以參考下

前言

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

本文分爲以下幾節說明redis lazy free：

lazy free的定義
我們爲什麼需要lazy free
lazy free的使用
lazy free的監控
lazy free實現的簡單分析

lazy free的定義

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

我們爲什麼需要lazy free

Redis是single-thread程序(除少量的bio任務),當運行一個耗時較大的請求時，會導致所有請求排隊等待redis不能響應其他請求，引起性能問題,甚至集羣發生故障切換。
而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) “"

測試估算，可參考；和硬件環境、Redis版本和負載等因素有關

Key類型	Item數量	耗時
Hash	~100萬	~1000ms
List	~100萬	~1000ms
Set	~100萬	~1000ms
Sorted Set	~100萬	~1000ms

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

例如：我們生產Redis Cluster大集羣，業務緩慢地寫入一個帶有TTL的2000多萬個字段的Hash鍵，當這個鍵過期時，redis開始被動清理它時，導致redis被阻塞20多秒，當前分片主節點因20多秒不能處理請求，併發生主庫故障切換。

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

lazy free的使用

lazy free的使用分爲2類：第一類是與DEL命令對應的主動刪除，第二類是過期key刪除、maxmemory key驅逐淘汰刪除。

主動刪除鍵使用lazy free

UNLINK命令

UNLINK命令是與DEL一樣刪除key功能的lazy free實現。

唯一不同時，UNLINK在刪除集合類鍵時，如果集合鍵的元素個數大於64個(詳細後文），會把真正的內存釋放操作，給單獨的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命令，還是併發阻塞的刪除操作

FLUSHALL/FLUSHDB ASYNC

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

127.0.0.1:7000> DBSIZE
(integer) 1812295
127.0.0.1:7000> flushall //同步清理實例數據，180萬個key耗時1020毫秒
OK
(1.02s)
127.0.0.1:7000> DBSIZE
(integer) 1812637
127.0.0.1:7000> flushall async //異步清理實例數據，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應用於被動刪除中，目前有4種場景，每種場景對應一個配置參數；默認都是關閉。

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

注意：從測試來看lazy free回收內存效率還是比較高的；但在生產環境請結合實際情況，開啓被動刪除的

lazy free 觀察redis內存使用情況。

lazyfree-lazy-eviction

針對redis內存使用達到maxmeory，並設置有淘汰策略時；在被動淘汰鍵時，是否採用lazy free機制；
因爲此場景開啓lazy free, 可能使用淘汰鍵的內存釋放不及時，導致redis內存超用，超過maxmemory的限制。此場景使用時，請結合業務測試。

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

針對設置有TTL的鍵，達到過期後，被redis清理刪除時是否採用lazy free機制；
此場景建議開啓，因TTL本身是自適應調整的速度。

lazyfree-lazy-server-del

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

slave-lazy-flush

針對slave進行全量數據同步，slave在加載master的RDB文件前，會運行flushall來清理自己的數據場景，
參數設置決定是否採用異常flush機制。如果內存變動不大，建議可開啓。可減少全量同步耗時，從而減少主庫因輸出緩衝區爆漲引起的內存使用增長。

lazy free的監控

lazy free能監控的數據指標，只有一個值：lazyfree_pending_objects，表示redis執行lazy free操作，在等待被實際回收內容的鍵個數。並不能體現單個大鍵的元素個數或等待lazy free回收的內存大小。

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

lazy free實現的簡單分析

antirez爲實現lazy free功能，對很多底層結構和關鍵函數都做了修改；該小節只介紹lazy free的功能實現邏輯；代碼主要在源文件lazyfree.c和bio.c中。

UNLINK命令

unlink命令入口函數unlinkCommand()和del調用相同函數delGenericCommand()進行刪除KEY操作，使用lazy標識是否爲lazyfree調用。如果是lazyfree,則調用dbAsyncDelete()函數。

但並非每次unlink命令就一定啓用lazy free，redis會先判斷釋放KEY的代價(cost),當cost大於LAZYFREE_THRESHOLD才進行lazy free.

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

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

所以可以看出，redis的lazy free的cost計算主要時間複雜度相關。

lazyfreeGetFreeEffort()函數代碼

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()函數的部分代碼

#define LAZYFREE_THRESHOLD 64 //根據FREE一個key的cost是否大於64，用於判斷是否進行lazy free調用
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當前key的代價
/* If releasing the object is too much work, let's put it into the
* lazy free list. */
if (free_effort > LAZYFREE_THRESHOLD) { //如果free當前key cost>64, 則把它放在lazy free的list, 使用bio子線程進行實際free操作，不通過主線程運行
atomicIncr(lazyfree_objects,1); //待處理的lazyfree對象個數加1，通過info命令可查看
bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL); 
dictSetVal(db->dict,de,NULL);
}
}
}

在bio中實際調用lazyfreeFreeObjectFromBioThread()函數釋放key

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

flushall/flushdb async命令

當flushall/flushdb帶上async,函數emptyDb()調用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創建兩個空的hash tables
db->expires = dictCreate(&keyptrDictType,NULL);
atomicIncr(lazyfree_objects,dictSize(oldht1)); //更新待處理lazyfree的鍵個數，加上db的key個數
bioCreateBackgroundJob(BIO_LAZY_FREE,NULL,oldht1,oldht2);//加入到bio list
}

在bio中實際調用lazyfreeFreeDatabaseFromBioThread函數釋放db

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

被動刪除鍵使用lazy free

被動刪除4個場景，redis在每個場景調用時，都會判斷對應的參數是否開啓，如果參數開啓，則調用以上對應的lazy free函數處理邏輯實現。

總結

因爲Redis是單個主線程處理，antirez一直強調"Lazy Redis is better Redis".

而lazy free的本質就是把某些cost(主要時間複製度，佔用主線程cpu時間片)較高刪除操作，從redis主線程剝離，讓bio子線程來處理，極大地減少主線阻塞時間。從而減少刪除導致性能和穩定性問題。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持神馬文庫。

Redis的新特性懶惰刪除Lazy Free詳解

Redis的新特性懶惰刪除Lazy Free詳解

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結