Redis作为一个高性能的缓存系统，在Web应用中被广泛使用，其快速、高效、可靠的优点备受青睐。

不过，之前的文章中也提到过Redis的一些操作也会导致阻塞【列举Redis十大阻塞原因分析和解决方案】，比如当处理大key时可能会出现阻塞的情况。

本文将深入分析Redis的del命令和unlink命令，在理解了它们的实现原理之后，详细阐述为什么del删除大key会导致阻塞，而unlink不会。

一、Redis的del命令

del命令的作用

del命令是Redis中用于删除键值对的命令。语法结构如下：

DEL key [key ...]

其中，参数key可以是单个键，也可以是多个键，表示要删除的键值对的键名。如果key不存在，则直接忽略。

del命令的实现原理

del命令的实现原理非常简单，它会直接将指定的键值对从内存中删除。具体流程如下：

① 根据传入的key查找相应的键值对。

② 如果找到了该键值对，则将其从内存中删除。

③ 如果传入的是多个key，则依次执行第①步和第②步。

del命令的阻塞问题

del命令是一种阻塞式操作，当需要删除的 key 比较多、value 比较大时，会占用较长时间，导致当前线程阻塞。这种情况下，其他客户端发送的请求也会被强制等待，直到删除操作完成。

为什么呢？因为Redis的内存由一块单独的 dict 结构维护，当使用 del 命令删除一个大 key 时，该 key 所对应的数据将完全存储在这个 dict 结构中。而 dict 结构是一个哈希表，删除元素的过程需要遍历所有元素，并将要删除的元素的空间释放回操作系统。如果要删除的元素比较多、数据比较大，则释放空间的操作可能非常耗时，导致整个删除过程被阻塞。

二、Redis的unlink命令

unlink命令的作用

unlink 命令是 Redis 4.0 之后增加的命令，也是用于删除键值对的命令。与 del 命令不同的是，它是异步删除，不会阻塞当前线程。语法结构如下：

UNLINK key [key ...]

其中，参数key可以是单个键，也可以是多个键，表示要删除的键值对的键名。如果key不存在，则直接忽略。

unlink命令的实现原理

unlink命令的实现原理与del命令有所不同。它并不会立即将指定的键值对从内存中删除，而是将其放入一个队列中，由后台线程负责异步删除。

具体流程如下：

① 根据传入的 key 查找相应的键值对。

② 如果找到了该键值对，则将其标记为"待删除"状态，并将其加入到一个专门用于存储待删除键值对的列表中。

③ 如果传入的是多个 key，则依次执行第①步和第②步。

unlink命令会将指定的键值对标记为"待删除"状态，并将其加入到一个专门用于存储待删除键值对的列表中，而不会立即从内存中删除。实际的删除操作是由 Redis 后台线程来负责的，在适当的时候进行异步删除。因此，在执行 unlink 命令后，key 并不会立即移除，而是等待后台线程完成异步删除操作，才会真正从内存中移除。虽然 key 没有被立即移除，但在这个过程中，如果有需要操作该key 的请求，还是会返回找不到 key 或者数据为空的结果。

unlink 一定是异步的吗？

其实 unlink 命令不一定是异步的，在 redis 的源码中有这么一段

// 惰性删除的阈值
#define LAZYFREE_THRESHOLD 64
// redis 异步删除的方法
int dbAsyncDelete(redisDb *db, robj *key) {
    if (dictSize(db->expires) > 0) dictDelete(db->expires,key->ptr);
    dictEntry *de = dictUnlink(db->dict,key->ptr);
    if (de) {
        robj *val = dictGetVal(de);
        size_t free_effort = lazyfreeGetFreeEffort(val);
        // val需要内存释放的空间长度超过惰性删除的阈值（64个字节），才把val放入异步线程
        if (free_effort > LAZYFREE_THRESHOLD && val->refcount == 1) {
            atomicIncr(lazyfree_objects,1);
            bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL);
            dictSetVal(db->dict,de,NULL);
        }
    }
    if (de) {
        // 删除过程，和del同步过程差不多
        dictFreeUnlinkedEntry(db->dict,de);
        if (server.cluster_enabled) slotToKeyDel(key->ptr);
        return 1;
    } else {
        return 0;
    }
}

由上面的源码可以看出，

1、当使用 unlink 命令时，要满足删除的 val 需要内存释放的空间长度超过惰性删除的阈值（64个字节），才把val放入异步线程；

2、unlink 的异步过程在删除 key 时，只是针对 val 的空间回收是异步的，对 key 的其它 Redis 空间回收还是同步的过程

三、del 和 unlink 的性能测试

假设我们有一个Redis实例，里面存储了100万个键值对，这些键的类型都是字符串类型，每个键的value大小均为1KB。我们可以通过性能测试来比较del和unlink命令的效率。

下面是一个示例表格，展示了删除数量从1万、5万、10万、100万时，使用del和unlink命令所需的时间（以秒为单位）：

从上面的测试结果可以看出，当要删除的key数量较少时，del命令和unlink命令的执行时间差别不明显；但当删除数量较多时，unlink命令的性能优势就比较明显了，可以明显减少删除操作所需的时间。

需要注意的是，这只是一个示例测试结果，实际情况可能会受到多种因素的影响，比如Redis实例的配置、硬件环境等，所以需要在实际环境中进行测试，以确定最佳的数据删除策略。

四、与 unlink 相关的 Redis 配置参数介绍

以下是几个常见的Redis配置参数，它们会影响unlink命令的执行效果：

maxmemory：这个参数定义了Redis实例能够使用的最大内存量。如果Redis的内存使用量超过了这个值，那么系统就可能会变得非常缓慢，从而影响unlink命令的执行效率。

maxmemory-policy：这个参数定义了Redis在达到最大内存限制后应该采取的策略。可选值包括noeviction、allkeys-lru和volatile-lru等。不同的策略会对unlink命令的执行效果产生不同的影响。

lazyfree-lazy-eviction：这个参数控制Redis是否启用lazy-free和lazy-eviction功能。如果开启这些功能，Redis可以异步删除键值对，从而提高unlink命令的执行效率。

activerehashing：这个参数控制Redis是否在执行rehash操作时占用主线程。如果这个参数被设置为no，则Redis会将rehash操作放到后台线程中处理，从而提高unlink命令的执行效率。

save：这个参数定义了Redis进行持久化操作的频率。如果设置得太频繁，可能会导致系统性能下降，从而影响unlink命令的执行效率。

需要注意的是，以上参数只是影响unlink命令执行效果的一部分，Redis还有许多其他参数也会对性能产生影响。因此，在实际应用中，需要根据具体情况综合考虑各种因素，以确保系统的性能和稳定性。