Redis del bigkey即使开启了lazyfree，为什么还是阻塞的，但是别人又不阻塞？why

本文主要是介绍Redis del bigkey即使开启了lazyfree，为什么还是阻塞的，但是别人又不阻塞？why，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Redis del bigkey之后为啥还是阻塞的呢？明明开启了lazyfree，为啥别人立马可以删除？

干货：[公粽号：堆栈future]

lazyfree redis 4.0引入

lazyfree-lazy-user-del 6.0引入

为什么del删除bigkey是阻塞的

lazy-free是4.0新增的功能，但是默认是关闭的，需要手动开启。你开启之后，然后用del删除一个几万的key，发现命令阻塞在那里了，你很郁闷，我都开启了，为撒还阻塞呢？莫非在逗我？

先说答案：你用错了命令，在你开启lazyfree之后，你得用redis提供的命令：unlink，用这个命令去删除就是异步了。

redis> UNLINK key1 key2 key3
(integer) 2

源码角度解释下为什么

手动开启lazy-free时，有4个选项可以控制，分别对应不同场景下，要不要开启异步释放内存机制：

lazyfree-lazy-expire：key在过期删除时尝试异步释放内存
lazyfree-lazy-eviction：内存达到maxmemory并设置了淘汰策略时尝试异步释放内存
lazyfree-lazy-server-del：执行RENAME/MOVE等命令或需要覆盖一个key时，删除旧key尝试异步释放内存
replica-lazy-flush：主从全量同步，从库清空数据库时异步释放内存

除了replica-lazy-flush之外，其他情况都只是可能去异步释放key的内存，并不是每次必定异步释放内存的。

开启lazy-free后，Redis在释放一个key的内存时，首先会评估代价，如果释放内存的代价很小，那么就直接在主线程中操作了，没必要放到异步线程中执行（不同线程传递数据也会有性能消耗）。

什么情况才会真正异步释放内存？这和key的类型、编码方式、元素数量都有关系（详细可参考源码中的lazyfreeGetFreeEffort函数）：

当Hash/Set底层采用哈希表存储（非ziplist/int编码存储）时，并且元素数量超过64个
当ZSet底层采用跳表存储（非ziplist编码存储）时，并且元素数量超过64个
当List链表节点数量超过64个（注意，不是元素数量，而是链表节点的数量，List的实现是在每个节点包含了若干个元素的数据，这些元素采用ziplist存储）
再加一个条件就是refcount=1 就是没有人在引用这个key的时候

只有以上这些情况，在删除key释放内存时，才会真正放到异步线程中执行，其他情况一律还是在主线程操作。

也就是说String（不管内存占用多大）、List（少量元素）、Set（int编码存储）、Hash/ZSet（ziplist编码存储）这些情况下的key在释放内存时，依旧在主线程中操作。

直接看源码：

size_t lazyfreeGetFreeEffort(robj *key, robj *obj, int dbid) {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 if (obj->type == OBJ_STREAM) {size_t effort = 0;stream *s = obj->ptr;}
}

lazyfreeGetFreeEffort函数判断下删除一个key的付出有多大，然后

#define LAZYFREE_THRESHOLD 64/* Free an object, if the object is huge enough, free it in async way. */
void freeObjAsync(robj *key, robj *obj, int dbid) {size_t free_effort = lazyfreeGetFreeEffort(key,obj,dbid);if (free_effort > LAZYFREE_THRESHOLD && obj->refcount == 1) {atomicIncr(lazyfree_objects,1);bioCreateLazyFreeJob(lazyfreeFreeObject,1,obj);} else {decrRefCount(obj);}
}

它被freeObjAsync这个函数调用，用来和64去判断并且同时判断引用是否为1.只有满足了大于64并且refcount==1，那么就会异步删除，异步删除就是把这个删除任务交由(bio系统)去处理，否则调用decrRefCount在主线称中同步删除，如果是用zmalloc申请的内存最后都是调用zfree删除。

可见，即使开启了lazy-free，String类型的bigkey，在删除时依旧有阻塞主线程的风险。所以，即便Redis提供了lazy-free，我建议还是尽量不要在Redis中存储bigkey。