您现在的位置是: 网站首页 > 程序设计  > redis 

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

2020年2月17日 08:00 976人围观

简介在Redis中,对于大KEY的删除一直是个比较头疼的问题,为了不影响服务,我们通常需要自己实现工具来删除大KEY,或者在业务低峰期进行删除操作。 为了解决以上问题, Redis 4.0 新添加了 UNLINK 命令用于执行大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);