背景

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

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

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

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

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

下面來看看如何做到的。

RDB 說明

關(guān)鍵操作符

其中 248 和 249 兩個(gè)是只會(huì)存在一個(gè)，但是它們又用的同一個(gè)數(shù)據(jù)結(jié)構(gòu)，所以要把它們放在一起來說明。

下面再看看一個(gè) key value 完整的“數(shù)據(jù)結(jié)構(gòu)”

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

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

rdb-cli 分析

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

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

首先是

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

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

圖片

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

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

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

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

圖片

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

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

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

小結(jié)

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

原因的話，object idletime 已經(jīng)告訴我們了。