Redis随笔-rename效率问题

Posted 2023-04-16

参考技术A

rename 是redis中给key重命名命令， rename key newkey 的意思就是将key重命名为newkey。
大部分文档在介绍 rename 的时候只将它描述成一个时间复杂度为O(1)的命令，却忘了说明它可能导致的性能问题（涉及覆盖旧值的时候 时间复杂度应该是O(1)+O(M))。

我们先做个试验看看 rename 的问题。

先搭建一个redis服务器，版本号为3.2，看看它的内存信息

接着用lua给redis创建一个名为 test 的大key， test 有500w个field，每个field的值都是1

这时候我们看看redis的内存占用情况

由于大key test 的创建，redis内存占用多了300多兆。
接下来我们创建一个临时key，并用它来 rename 掉大key test

这时就能看到执行时间的异常了， rename 执行时间长达2.36秒，这是为什么呢？我们再看看redis内存占用情况:

通过 info 返回的信息我们可以发现在执行 rename 之后redis将大key test 大小为300多兆的值对象直接删除并回收掉了，而redis删除一个key的时间复杂度是O(M)，在这里M是被删除的成员数量---500w。应该就是这个 "隐式"删除操作 导致了高延迟的产生。

我们看看官方文档是怎么描述 rename 这一行为的：

newkey如果本就存在，redis会用key的值覆盖掉newkey的值， 而newkey原本的值会被redis隐式地删除 。我们知道大key的删除伴随着高延迟（redis是单进程服务，服务器会在删除大key期间block住接下来其他命令的执行），这就导致时间复杂度本为O(1)的 rename 也有可能卡住redis。

这句官方文档的原话我没在其他文档里找到类似的翻译，看这些文档的开发者可能会误以为这是个特别安全的O(1)命令。

既然文档里已经说明了这种行为的存在，我就顺便看看源码这块逻辑是怎么走的：

正常O(1)重命名的逻辑不用多说，涉及到覆盖的过程可以简化成如下图：

在改变指针的指向之前，redis会先用 if (lookupKeyWrite(c->db,c->argv[2]) != NULL) 判断 newkey 是否有对应的值，若有 则调用 dbDelete(c->db,c->argv[2]); 将newkey的值 v2 删掉。

用redis的时候， keys 、 hgetall 、 del 这些命令我们会多加小心，因为不合理地调用它们可能会长时间block住redis的其他请求 甚至导致CPU使用率居高不下从而卡住整个服务器。但其实 rename 这个不起眼的命令也可能造成一样的问题，使用时也需要谨慎对待。

RENAME – Redis

Reids命令解析-RENAME

有一天开发突然照过来问，维萨我这个Redis实例这么慢呢？为什么这么慢，于是连上实例SLOWLOG 一看，这些慢日志都是大部分是RENMAE操作导致的，可是为什么RENAME操作会慢呢？不就是改个名字么？ 难道它还做了别的事？ 又或者学习Linux 的mv 操作？ 先copy 再DEL ？ 
于是带着这个问题，问问来拜访一下REDIS源码，看看为什么RENAME操作会慢的？在Redis中RENAME相关命令有两个 rename、renamenx。 
我们找到入库函数 server.c [struct redisCommand redisCommandTable[] = {}]，定位到renameCommand，可以发现这两个命令后端都是调用同一个函数[ renameGenericCommand(c,N)]，只是这个N这个值不同而已 
所以问题就很简单了， 我们只需要知道 [renameGenericCommand] 这个函数到底做了什么操作即可，定位到这个函数不难发现，对于Rename 命令会做以下操作：

1. 先对比 rename 中的两个KEY是不是一样，如果不相同则继续
2. 对第一个KEY在db 中查找，如果存在则继续，并记录 value 对象地址
3. 获取这个KEY 的过期时间，继续下一步
4. 尝试着查找第二个KEY，如果第二个KEY存在则删除第二个KEY
5. 把第二个KEY名字和第一个KEY的value 作为K-V 添加到DB中
6. 如果第一个KEY有过期时间，则为该KEY设置过期时间
7. 最后删除掉第一个KEY

精简过得源代码如下：

void renameGenericCommand(client *c, int nx) {
    robj *o;
    long long expire;
    int samekey = 0;

    if (sdscmp(c->argv[1]->ptr,c->argv[2]->ptr) == 0) samekey = 1;

    if ((o = lookupKeyWriteOrReply(c,c->argv[1],shared.nokeyerr)) == NULL) return;

    if (samekey) return;
    incrRefCount(o);
    expire = getExpire(c->db,c->argv[1]);
    if (lookupKeyWrite(c->db,c->argv[2]) != NULL) {
        dbDelete(c->db,c->argv[2]);
    }
    dbAdd(c->db,c->argv[2],o);
    if (expire != -1) setExpire(c,c->db,c->argv[2],expire);
    dbDelete(c->db,c->argv[1]);
}

所以通过以上我们可以得到如下结论： 
实际上RENAME = Query * 2 + ADD + [ DEL ] + [ EXPIRE ]

而对于RENAMENX = Query * 2 + ADD + [ EXPIRE ] ，这里一定没有DEL操作

对于内存数据库REDIS 来说， QUERY 、ADD 、EXPIRE 都是很快的，但是对于某些KEY DEL则不一定块，如果这个KEY的内存占用比较多，那么DEL 是个比较慢的过程。

OK，结论似乎有了， 那么需要进一步的来验证一下这个结论，怎么验证呢？很简单，我们可以GET 出来看看这个KEY 有多大， 或者使用 DEBUG OBJECT　XXXKEY 看一下序列化后的内存大小。

OK，结论也有了，也验证了,看起来是 大KEY 惹的货啊， 那么对于我们怎么找到这些大KEY，如果进行删除，请查看我的前两篇文章 :)