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没啥区别了。