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。
那为什么有人能del bigkey成功呢？
能del一个bigkey成功的，一定是因为他所用的redis版本是6.0及以上的。redis增加了一个配置项：lazyfree-lazy-user-del，只要开启了，del直接可以异步删除key了，这就和unlink没啥区别了。
