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个选项可以控制，分别对应不同场景下，要不要开启异步释放内存机制：

1. lazyfree-lazy-expire：key在过期删除时尝试异步释放内存

2. lazyfree-lazy-eviction：内存达到maxmemory并设置了淘汰策略时尝试异步释放内存

3. lazyfree-lazy-server-del：执行RENAME/MOVE等命令或需要覆盖一个key时，删除旧key尝试异步释放内存

4. 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。

那为什么有人能del bigkey成功呢？

能del一个bigkey成功的，一定是因为他所用的redis版本是6.0及以上的。redis增加了一个配置项：lazyfree-lazy-user-del，只要开启了，del直接可以异步删除key了，这就和unlink没啥区别了。

堆栈future

使很多处于迷茫阶段的coder能从这里找到光明，堆栈创世，功在当代，利在千秋

121篇原创内容