一臺Redis服務器在很短的時間里消耗了幾十個G的內(nèi)存，最終因為SWAP而宕機。因為這臺服務器的社會背景比較復雜，所以一時無法判斷犯罪嫌疑人到底是誰。

最開始的直覺是認為肯定有人保存了大體積的數(shù)據(jù)，于是問題就變成了找出哪些鍵占用的空間比較大，DBA同事用了redis-rdb-tools等工具來分析數(shù)據(jù)文件?？上У氖请m然找到了一些大體積的鍵，但最終都排除了嫌疑，問題似乎陷入了僵局。

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

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

悲催的是一運行這個命令服務器就掛了！因為數(shù)據(jù)太多了，所以KEYS受不了。此時應該使用SCAN，它有游標的概念，每次迭代只涉及很少的數(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);
}

?>

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

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

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