Redis4.0新特性之-大KEY删除

阅读更多

在Redis中,对于大KEY的删除一直是个比较头疼的问题,为了不影响服务,我们通常需要自己实现工具来删除大KEY,或者在业务低峰期进行删除操作。 
为了解决以上问题, Redis 4.0 新添加了 UNLINK 命令用于执行大KEY异步删除。那么这个异步删除的背后的逻辑是什么?

通过源码我们可以的得知以下信息: 
当我们调用异步删除UNLINK命令时:

  1. 释放掉Expire Dicti 对 K-V 的引用
  2. 释放Main Dict 对 K-V 的引用,同时记录下这个K-V 的 Entry地址
  3. 计算释放掉这个V 所需要的代价,计算方法如下: 
    3.1 如果这个V 是一个 String 类型,则代价为 1 
    3.2 如果这个V 是一个复合类型,则代价为 该复合类型的长度,比如,list 则为 llen 的结果,hash 则为 hlen 的结果 …
  4. 根据得到的代价值,和代价阈值比对,如果小于 64 则,可以直接释放掉K-V 内存空间;如果大于 64 则,把该V 放入lazyfree 队列中,同时启动一个BIO后台JOB进行删除 
    4.1 在后台线程对 V 进行删除时,也是根据不同类型的 V 做不同的操作 
    4.2 如果是 LIST 类型,则根据LIST 长度,则直接释放空间。 
    4.3 如果是 SET 类型,并且数据结构采用 HASH 表存储,那么遍历整个hash表,逐个释放 k,v空间;如果数据结构采用 intset,则直接释放空间即可 
    4.4 如果是 ZSET 类型,并且数据结构采用 SKIPLIST 存储,由于 SKIPLIST 底层采用 HASH + skiplist 存储,那么会先释放掉 SKIPLIST 中 hash 存储空间,再释放掉 SKIPLIST 中 skiplist 部分; 如果数据结构采用 ZIPLIST 存储,则直接释放空间。 
    4.5 如果是 HASH 类型,并且数据结构采用 HASH表存储,则遍历整个hash表,逐个释放 k,v空间;如果数据结构采用 ZIPLIST 存储,则直接释放空间。
  5. 设置 V 值等于NULL
  6. 释放掉 K-V 空间

异步删除代码如下 :

int dbAsyncDelete(redisDb *db, robj *key) {
    /*  */
    if (dictSize(db->expires) > 0) dictDelete(db->expires,key->ptr); /* 在Main Dict 链表去掉引用,得到K-V entryDict */ dictEntry *de = dictUnlink(db->dict,key->ptr); if (de) { robj *val = dictGetVal(de); size_t free_effort = lazyfreeGetFreeEffort(val); /* 计算DEL key 的代价,根据代价决定是否采用异步删除方式 */ if (free_effort > LAZYFREE_THRESHOLD) { atomicIncr(lazyfree_objects,1,lazyfree_objects_mutex); bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL); dictSetVal(db->dict,de,NULL); } } /* 释放K-V空间,或者采用了异步删除方式,只需要释放Key空间 */ if (de) { dictFreeUnlinkedEntry(db->dict,de); if (server.cluster_enabled) slotToKeyDel(key); return 1; } else { return 0; } } /* 释放LIST 空间 */ void quicklistRelease(quicklist *quicklist) { unsigned long len; quicklistNode *current, *next; current = quicklist->head; len = quicklist->len; while (len--) { next = current->next; zfree(current->zl); quicklist->count -= current->count; zfree(current); quicklist->len--; current = next; } zfree(quicklist); } /* 释放HASH表空间 */ static int _dictClear(dict *ht) { unsigned long i; for (i = 0; i < ht->size && ht->used > 0; i++) { dictEntry *he, *nextHe; if ((he = ht->table[i]) == NULL) continue; while(he) { nextHe = he->next; dictFreeEntryKey(ht, he); dictFreeEntryVal(ht, he); free(he); ht->used--; he = nextHe; } } free(ht->table); _dictReset(ht); return DICT_OK; /* never fails */ } 

由于异步删除实际上是先在MAIN DICT 里边把 这个K,V 的引用关系去掉了,所以当我们再次查询这个Key 的时候是查不到的,然后在慢慢释放Value 所占用的内存空间。

我们发现在异步进行删除的时候,不管是删除 HASH也好,还是QUICKLIST 也罢,这部分其实并没有进行一个速度的控制,只是起了一个线程让他去删除,能跑多快就跑多快,这样可能会导致我们在进行删除的时候CPU飙高。

这个删除大KEY是在Master 上进行的,如果这个节点有Slave呢?slave 会进行怎样的操作?同样根据代码可以发现,我们在执行UNLINK操作时,实际上在 AOF 和 通知Slave的时候只是发送了一条DEL xxkey 命令,当slave 收到del命令时,会采取以上同样的判断对这个key进行删除。

notifyKeyspaceEvent(NOTIFY_GENERIC,"del",c->argv[j],c->db->id);

 

http://www.cnblogs.com/svan/p/7054129.html

你可能感兴趣的:(Redis4.0新特性之-大KEY删除)