背景

我們在使用 Redis 的過程中，有時候會想要知道某些 key 是否長時間沒有被訪問，如果這些 key 長時間沒有人訪問，并且還占用了比較大的內存空間時，我們就會想及時的清理掉這些 key。

Redis 本身提供了一個 OBJECT IDLETIME 的命令可以讓我們來查詢某個 key 最后一次被訪問后的秒數。

https://redis.io/commands/object-idletime/

但是這個命令對于分析整個 Redis 實例時會顯得十分吃力，免不了 scan + object idletime 的組合。

如果能把這個時間從 rdb 文件讀出來再進行分析，可以有效減少對線上實例的影響，同時效率也會高不少。

下面來看看如何做到的。

RDB 說明

關鍵操作符

其中 248 和 249 兩個是只會存在一個，但是它們又用的同一個數據結構，所以要把它們放在一起來說明。

下面再看看一個 key value 完整的“數據結構”

252 EXPIRE_TIME_MS|253 EXPIRE_TIME|249 LFU 或 248 LRU|xxx VALUE_TYPE|xxx KEY|xxx VALUE|

可以看到第三部分就是我們所需要的。

rdb-cli 分析

rdb-cli 是老黃寫的一個開源 rdb 文件分析器，源碼地址：https://github.com/catcherwong/rdb-tools，感興趣的可以關注一下。

rdb-cli 里面有兩個命令用于做這一塊的分析。

首先是

rdb-cli memory \
    -ot html \
    --sep-count 3 \
    /tmp/biz_a_20240301.rdb

執(zhí)行這個之后，會生成一個 res.html 文件，打開這個文件會看到下面兩個圖：

圖片

這兩個圖就是所有 key 的空閑分布，可以看到，就數量而言，這個 redis 實例，有超過 100w 的 key 是在 7天內沒有過訪問的??！

有這個大致分布，但是還看不到具體的細節(jié)，所以我們要用另外一個命令來看具體是那些 key 這么離譜。

rdb-cli csv \
    --min-idle 604800 \
    /tmp/biz_a_20240301.rdb

執(zhí)行這個之后，會生成一個 dump.csv 文件，打開這個文件可以看到下面的內容：

圖片

著重看 idle 這一列，單位是秒。

可以看到超過 7天 沒訪問的，最長的有 16693102 秒，換算成天，是 193 天，接近 200 天。這種數據就不應該存在 redis 里面！

兩個命令，用起來還算是比較方便的，也比較快得到結果，當然上述兩個命令還有其他的過濾條件可以結合使用，用 -h 即可查看。

小結

對于設置了 LRU 相關策略的 Redis 實例才可以用這個方法去分析空閑分布，如果是 LFU 相關策略的，則無法看到空閑分布?。?/p>

原因的話，object idletime 已經告訴我們了。