Redis 原理： 大key为什么阻塞

在Redis的删除中，通常调用del 语法来执行Key的删除，但如果是大key，那有可能会阻塞线程，导致其他的连接也会受影响，那为什么呢？今天我们先从源码分析下删除的逻辑是怎么样的？

当调用del 命令时，服务端会调用 delCommand 方法(从前面的 redis 启动方式中对于命令的执行方式可以找到)。

不管是同步删除还是异步删除，最终都是调用以下的方法

这里会做几件事：

1. 删除过期列表中指定的key数据
2. 将dict中的对象进行移除
3. 如果是异步处理，则只释放key的内存，value的处理也会进行判断，如果value是hash、list、set、zset 等复杂对象，它的元素大于64,则会加入异步队列中待由异步线程处理，相反则会走同步删除，处理完成后，则将key对应的value 设置成null，便于后续的动作只释放key内存

1. 同时处理会调用dictFreeUnlinkedEntry

这两个在Redis服务器启动时就会进行初始化

接下去看看dictSdsDestructor 与 dictObjectDestructor的处理方式

1. dictSdsDestructor 比较简单，直接释放内存
2. 而dictObjectDestructor 则调用 decrRefCount ,不同的类型使用不同的方式

如list 如下：

因为每种类型的底层对应的存储方式不同，但一定是要对于每个元素进行释放，所以需要进行遍历，如果是同步的情况下，且删除的key对应的value是一个元素很多的值，称为大key，那么在删除时，就有可能这个del动作就会阻塞，导致redis的其他的客户端连接等待。

而刚才在开始的时候，有说到一个 lazyfree_lazy_user_del 这个参数，可以将客户端发送的del 命令，主动以lazy_free的方式进行处理。

而在redis 4.0以后，有引入 unlink 命令进行以lazy_free的方式进行删除key，以异步线程进行处理，对于大key就不会有阻塞的影响。

至此 del的处理逻辑，大致分析完成，来总结下：

1. del 可以是同步(默认)或是异步来处理
2. 非string类型的大key的处理方式，不能直接以del 方式来处理，会阻塞redis的响应
3. 对于大key的处理，需要进行统计对应的列表大小，并通过各个类型中的列表进行多次批量的处理，而不是一次性使用del