摘要：現(xiàn)象先搭建一個服務器，版本號為，看看它的內存信息接著用給創(chuàng)建一個名為的大，有個，每個的值都是這時候我們看看的內存占用情況由于大的創(chuàng)建，內存占用多了多兆。但其實這個不起眼的命令也可能造成一樣的問題，使用時需要謹慎對待。

rename是redis中給key重命名命令，rename key newkey的意思就是將key重命名為newkey。
大部分文檔在介紹rename的時候只將它描述成一個時間復雜度為O(1)的命令，卻忘了說明它可能導致的性能問題（涉及覆蓋舊值的時候 時間復雜度應該是O(1)+O(M))。

我們先做個試驗看看rename的問題。

先搭建一個redis服務器，版本號為3.2，看看它的內存信息

127.0.0.1:8401> info memory
# Memory
used_memory:842416
used_memory_human:822.67K

接著用lua給redis創(chuàng)建一個名為 test的大key，test有500w個field，每個field的值都是1

127.0.0.1:8401> eval "for i=1,5000000,1 do redis.call("hset","test", i,1) end" 0
(nil)
(11.61s)
127.0.0.1:8401> hlen test
(integer) 5000000

這時候我們看看redis的內存占用情況

127.0.0.1:8401> info memory
# Memory
used_memory:381185592
used_memory_human:363.53M

由于大key test的創(chuàng)建，redis內存占用多了300多兆。
接下來我們創(chuàng)建一個臨時key，并用它來rename掉大key test

127.0.0.1:8401> set tmp 1
OK
127.0.0.1:8401> rename tmp test
OK
(2.36s)

這時就能看到執(zhí)行時間的異常了，rename執(zhí)行時間長達2.36秒，這是為什么呢？我們再看看redis內存占用情況:

127.0.0.1:8401> info memory
# Memory
used_memory:821528
used_memory_human:802.27K

通過info返回的信息我們可以發(fā)現(xiàn)在執(zhí)行rename之后redis將大key test大小為300多兆的值對象直接刪除并回收掉了，而redis刪除一個key的時間復雜度是O(M)，在這里M是被刪除的成員數(shù)量---500w。應該就是這個"隱式"刪除操作導致了高延遲的產生。

我們看看官方文檔是怎么描述rename這一行為的：

RENAME key newkey
Renames?key?to?newkey. It returns an error when?key?does not exist. If?newkey?already exists it is overwritten, when this happens?RENAMEexecutes an implicit?DEL?operation, so if the deleted key contains a very big value it may cause high latency even if?RENAME?itself is usually a constant-time operation.

newkey如果本就存在，redis會用key的值覆蓋掉newkey的值，而newkey原本的值會被redis隱式地刪除。我們知道大key的刪除伴隨著高延遲（redis是單進程服務，服務器會在刪除大key期間block住接下來其他命令的執(zhí)行），這就導致時間復雜度本為O(1)的rename也有可能卡住redis。

這句官方文檔的原話我沒在其他文檔里找到類似的翻譯，看這些文檔的開發(fā)者可能會誤以為這是個特別安全的O(1)命令。

既然文檔里已經說明了這種行為的存在，我就順便看看源碼這塊邏輯是怎么走的：

db.c
void renameCommand(client *c) {                                                                                        
    renameGenericCommand(c,0);
}
void renameGenericCommand(client *c, int nx) {
    robj *o;
    ...
    if ((o = lookupKeyWriteOrReply(c,c->argv[1],shared.nokeyerr)) == NULL) //舊key的值對象地址復制給o
        return;
    ...
    incrRefCount(o); //舊key的值對象引用計數(shù)+1(被o引用)
    if (lookupKeyWrite(c->db,c->argv[2]) != NULL) { //如果新key已經有值對象了
        ...
        dbDelete(c->db,c->argv[2]); //新key從db中移除、并將新key的值對象引用計數(shù)-1(變?yōu)?)，并釋放內存
    }
    dbAdd(c->db,c->argv[2],o);  //將新key => 舊key的值對象的組合放入db中
    ...
    dbDelete(c->db,c->argv[1]); //舊key從db中移除、并將舊key的值對象引用計數(shù)-1(不會變?yōu)?)，不釋放內存
    ...
}

正常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