DEL 和 UNLINK区别?同步还是异步?

使用DEL命令会触发「同步删除」,如果Key是一个有很多元素的复杂类型,这个过程可能会堵塞一下Redis服务自身,从而影响用户的访问。

使用UNLINK命令,Redis服务会先计算删除Key的成本,从而更智能地做出「同步删除」或「异步删除」的选择。

成本计算:

对于list,hash,set,zset的对象类型,如果长度大于64(由宏LAZYFREE_THRESHOLD定义),才会采用异步删除的手段,从当前db先释放该key,再由另外一个线程做异步删除。对于长度不大于64的复杂类型,异步删除比同步删除还多了一些函数调用与多线程同步的代价,所以同步删除更好。对于string对象,底层的数据结构sds是一份连续的内存,内存分配器回收这块内存的复杂度是O(1),所以采用同步删除也不会堵塞服务。

总的来说,我们作为用户,都能用UNLINK替代DEL。

驱逐策略

Redis通过参数maxmemory来选择不同的驱逐策略:

  • volatile-random 从已设置过期时间的数据集(server.db[i].expires)中任意选择数据驱逐;volatile-lru 从数据集(server.db[i].dict)中挑选最近最少使用的数据驱逐(2.8默认);
  • volatile-ttl 从已设置过期时间的数据集(server.db[i].expires)中寻找最近即将过期(ttl最小)的key来驱逐;
  • allkeys-random 从数据集(server.db[i].dict)中任意选择数据驱逐;
  • allkeys-lru 从数据集(server.db[i].dict)中挑选最近最少使用的数据驱逐;
  • noeviction 禁止驱逐数据,永远不驱逐,仅对写操作返回一个错误(4.0默认);

在4.0版本后,还增加了以下两种驱逐策略。

  • volatile-lfu在过期集合中使用LFU链来驱逐数据;
  • allkeys-lfu 从数据集(server.db[i].dict)使用LFU算法来驱逐数据;

4.0后,在返回写入失败前,还会先检测lazyfree线程是否还有待删除的Key,没有才会给用户返回写入失败。

在4.0或以上的版本,Key的驱逐会基于参数lazyfree_lazy_eviction,来决定采用unlink还是del。在2.8版本,则只会用del。

 

Key的访问淘汰

对于Slave节点,访问到了已过期的Key,Slave节点会返回该Key不存在,但不会主动删除该Key。删除的动作,还是会从Master上同步过来。

对于Master节点,在4.0或以上的版本,会根据参数lazyfree-lazy-expire,来决定用DEL还是UNLINK。对于2.8版本,则只能用DEL了。这些删除的动作,都会同步到Slave与AOF文件中。

Key的定时淘汰

多久会执行一次定时调度呢?

redis服务的参数hz能控制定时淘汰的频率,hz默认是10,即每秒能调度100次。

定时淘汰一定是在master上发生的吗? 

有些时候,用户会把Slave节点设置成可写,那么Slave上写的带有过期时间的Key,因为Master是不知道的,就一直不会淘汰掉。所以在版本4.0以后,Redis增加了单独的逻辑,在定时淘汰中删除这些在slave节点上写入的过期Key。

“FAST淘汰”和“SLOW淘汰”?

前者每次淘汰只能花1毫秒,不能花更多了,后者是以hz=10为例,每次调度的总时间是100ms,这里调度不会25%的cpu时间,即25ms。

如果每淘汰1个Key就检测一次,无疑代价太大。从源码上看,定时淘汰会尝试遍历每个db,遍历完了或者时间到了就退出循环。第一层循环是遍历各个db,第二层循环是遍历db里面的一批批key,一批key是20个,如果第三层循环结束后有大于5个key是成功淘汰的(说明这个db很多淘汰key),那么二层就继续循环,如果小于等于5个key,说明这个db没有很多key需要淘汰,则退出二层循环,第三层循环是一批key里面逐个key进行淘汰。即最多320个key进行判断后,就会看看是否已经超过cpu占用时间。

在4.0或以上的版本,会根据参数lazyfree-lazy-expire(默认no)来做DEL还是UNLINK。

 

总结

 1.驱逐策略的选择,往往与业务特点、使用场景紧密相关。不当的选择,可能会让用户丢失不想丢失的数据,或者导致较差的驱逐效率; 

2.已过期的Key往往不会立刻被删除,用户在导出快照与建立主从时,会疑惑主从之间的Key数量不一致,我们都需要了解这一点; 

3.驱逐与淘汰都有可能影响服务,在新版本下,最好都开启unlink代替del。