Redis4.0新特性之-大KEY删除-西湖歌舞几时休

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

当我们调用异步删除UNLINK命令时：

释放掉Expire Dicti 对 K-V 的引用
释放Main Dict 对 K-V 的引用，同时记录下这个K-V 的 Entry地址<
计算释放掉这个V 所需要的代价，计算方法如下：
3.1 如果这个V 是一个 String 类型，则代价为 1
3.2 如果这个V 是一个复合类型，则代价为该复合类型的长度，比如，list 则为 llen 的结果，hash 则为 hlen 的结果 …
根据得到的代价值，和代价阈值比对，如果小于 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 存储，则直接释放空间。
设置 V 值等于NULL
释放掉 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);