为什么 redis RENAME 执行隐式 DEL 而不是 UNLINK？答案

【问题标题】：Why redis RENAME executes an implicit DEL rather than UNLINK?为什么 redis RENAME 执行隐式 DEL 而不是 UNLINK？
【发布时间】：2020-10-30 05:27:17
【问题描述】：

正如docs of RENAME 所说：

将密钥重命名为新密钥。当 key 不存在时返回错误。如果 newkey 已经存在，它会被覆盖，当这种情况发生时 RENAME 执行隐式 DEL 操作，因此如果删除的键包含一个非常大的值，它可能会导致高延迟，即使 RENAME本身通常是一个常数时间的操作。

我们知道，DEL 是阻塞的，而 UNLINK 是非阻塞的。

所以我有两个问题：

如果删除的键包含非常大的值，似乎执行隐式 UNLINK 会更好。为什么redis决定使用DEL？
如果我手动执行 UNLINK 然后 RENAME with transaction，是否可以避免高延迟？

【问题讨论】：

标签： redis

【解决方案1】：

“隐式 DEL 操作”与用户调用的 DEL 命令不同。您可以将其配置为使用异步或同步删除。其背后的原因可能是为了给用户更多的控制权。

在 redis 配置文件中，LAZY FREEING 部分显示

FLUSHALL 和 FLUSHDB 的 DEL、UNLINK 和 ASYNC 选项由用户控制。由应用程序的设计来了解何时是好的使用其中一个的想法。然而，Redis 服务器有时必须删除键或刷新整个数据库作为其他操作的副作用。** 具体来说，Redis 独立于用户调用删除对象以下场景：

.... 例如，RENAME 命令可能会在将旧密钥内容替换为 >another 时删除它。 ....

在上述所有情况下，默认都是以阻塞的方式删除对象，就像调用 DEL 一样。但是您可以具体配置每种情况 为了以非阻塞方式释放内存，例如如果 UNLINK 被调用，使用以下配置指令。

然后是配置

lazyfree-lazy-server-del no

只需将其切换为 YES，它的行为就会像 UNLINK

我检查了源代码，

对于 Redis 5.0 版本，调用 RENAME 命令时会调用该函数

void renameGenericCommand(client *c, int nx) {
// some code....
// When source and dest key is the same, no operation is performed,
// if the key exists, however we still return an error on unexisting key. 
if (sdscmp(c->argv[1]->ptr,c->argv[2]->ptr) == 0) samekey = 1;

// some code ...

if (samekey) {
    addReply(c,nx ? shared.czero : shared.ok);
    return;
}
       ...
    /* Overwrite: delete the old key before creating the new one
     * with the same name. */
    dbDelete(c->db,c->argv[2]);
}

这是它调用的dbDelete函数

int dbDelete(redisDb *db, robj *key) {
return server.lazyfree_lazy_server_del ? dbAsyncDelete(db,key) :
                                         dbSyncDelete(db,key);

}

如您所见，它确实引用了 lazyfree-lazy-server-del 的配置

【讨论】：