UNLINK命令是否总是比DEL命令好? [英] Is the UNLINK command always better than DEL command?

问题描述

在Redis 4.0中，有一个新命令 UNLINK 删除Redis内存中的密钥.

In Redis 4.0, there is a new command UNLINK to delete the keys in Redis memory.

此命令与DEL非常相似:它将删除指定的键. 就像DEL一样，如果密钥不存在，则将其忽略.但是，那 命令在另一个线程中执行实际的内存回收， 因此它不会阻止，而DEL是.这是命令名称 来自:该命令只是将键与键空间断开链接.这 实际的删除操作将稍后异步进行.

This command is very similar to DEL: it removes the specified keys. Just like DEL a key is ignored if it does not exist. However the command performs the actual memory reclaiming in a different thread, so it is not blocking, while DEL is. This is where the command name comes from: the command just unlinks the keys from the keyspace. The actual removal will happen later asynchronously.

因此，由于UNLINK是非阻塞的，因此可以始终(100％次)使用UNLINK而不是 DEL DEL，对吧?

So one can always (100% times) use UNLINK instead of DEL as UNLINK is nonblocking, unlike DEL, right?

推荐答案

在讨论哪个更好之前，让我们看一下这些命令之间的区别. DEL和UNLINK都在阻止模式下释放了关键部分.区别在于他们释放价值部分的方式.

Before discussing which one is better, let's take a look at the difference between these commands. Both DEL and UNLINK free the key part in blocking mode. And the difference is the way they free the value part.

DEL始终在阻塞模式下释放值部分.但是，如果该值太大，例如对于较大的LIST或HASH分配过多，会长时间阻止Redis.为了解决该问题，Redis实现了UNLINK命令，即非阻塞"删除.

DEL always frees the value part in blocking mode. However, if the value is too large, e.g. too many allocations for a large LIST or HASH, it blocks Redis for a long time. In order to solve the problem, Redis implements the UNLINK command, i.e. an 'non-blocking' delete.

实际上，UNLINK并非总是非阻塞/异步.如果值很小，例如LIST或HASH的大小小于64，该值将立即释放.这样，UNLINK与DEL几乎相同，除了它比DEL花费更多的函数调用之外.但是，如果值很大，则Redis会将值放入列表中，并且该值将由另一个线程释放，即非阻塞释放.这样，主线程必须与后台线程进行一些同步，这也是一个代价.

In fact, UNLINK is NOT always non-blocking/async. If the value is small, e.g. the size of LIST or HASH is less than 64, the value will be freed immediately. In this way, UNLINK is almost the same as DEL, except that it costs a few more function calls than DEL. However, if the value is large, Redis puts the value into a list, and the value will be freed by another thread i.e. the non-blocking free. In this way, the main thread has to do some synchronization with the background thread, and that's also a cost.

结论是，如果值较小，则DEL至少与UNLINK一样好.如果值很大，例如LIST具有成千上万个项目，UNLINK比DEL好得多.您始终可以安全地将DEL替换为UNLINK.但是，如果您发现线程同步成为问题(多线程总是令人头疼)，则可以回滚到DEL.

In a conclusion, if the value is small, DEL is at least, as good as UNLINK. If value is very large, e.g. LIST with thousands or millions of items, UNLINK is much better than DEL. You can always safely replace DEL with UNLINK. However, if you find the thread synchronization becomes a problem (multi-threading is always a headache), you can rollback to DEL.

更新:

从Redis 6.0开始，有一个新配置: lazyfree-lazy-user-del .您可以将其设置为 yes ，Redis将像运行UNLINK命令一样运行DEL命令.

Since Redis 6.0, there's a new configuration: lazyfree-lazy-user-del. You can set it to be yes, and Redis will run the DEL command as if running a UNLINK command.

这篇关于UNLINK命令是否总是比DEL命令好?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！