一臺(tái)Redis服務(wù)器在很短的時(shí)間里消耗了幾十個(gè)G的內(nèi)存，最終因?yàn)镾WAP而宕機(jī)。因?yàn)檫@臺(tái)服務(wù)器的社會(huì)背景比較復(fù)雜，所以一時(shí)無(wú)法判斷犯罪嫌疑人到底是誰(shuí)。

最開(kāi)始的直覺(jué)是認(rèn)為肯定有人保存了大體積的數(shù)據(jù)，于是問(wèn)題就變成了找出哪些鍵占用的空間比較大，DBA同事用了redis-rdb-tools等工具來(lái)分析數(shù)據(jù)文件。可惜的是雖然找到了一些大體積的鍵，但最終都排除了嫌疑，問(wèn)題似乎陷入了僵局。

在被直覺(jué)帶入死胡同之后，我們開(kāi)始調(diào)整調(diào)查的角度：即便一個(gè)鍵本身占用的空間并不大，但是如果相同模式的鍵數(shù)量很多的話，那么合計(jì)起來(lái)一樣會(huì)占用大量空間，于是問(wèn)題就變成了找出哪些相同模式的鍵占用的空間比較大。這次我不想用什么工具，而是打算在測(cè)試服務(wù)器上一邊刪除可疑鍵一邊查看內(nèi)存變化情況：

shell> /path/to/redis-cli keys foo:* | xargs /path/to/redis-cli del

悲催的是一運(yùn)行這個(gè)命令服務(wù)器就掛了！因?yàn)閿?shù)據(jù)太多了，所以KEYS受不了。此時(shí)應(yīng)該使用SCAN，它有游標(biāo)的概念，每次迭代只涉及很少的數(shù)據(jù)。

直接在命令行使用SCAN有些麻煩，于是我用了PHP：

<?php

$redis = new Redis();
$redis->setOption(Redis::OPT_SCAN, Redis::SCAN_RETRY);

$match = 'foo:*';
$count = 10000;

while ($keys = $redis->scan($it, $match, $count)) {
    $redis->del($keys);
}

?>

在刪除的同時(shí)注意監(jiān)控內(nèi)存變化情況，就能確認(rèn)問(wèn)題了：

shell> watch -d -n 1 '/path/to/redis-cli info | grep memory'

至于可疑鍵的獲取，我是瞎蒙的，簡(jiǎn)單通過(guò)MONITOR或者SCAN獲取采樣數(shù)據(jù)即可，另外從此案例看，監(jiān)控鍵總數(shù)的變化幅度是很重要的，從INFO里能拿到它。