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.

所以人们总是可以(100% 次)使用 UNLINK 而不是 DEL 因为 UNLINK 是非阻塞的，不像德尔，对吗?

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屋！