怎么在Redis里按模式刪除數(shù)據(jù)

小編給大家分享一下怎么在redis里按模式刪除數(shù)據(jù)，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

成都創(chuàng)新互聯(lián)是專業(yè)的柴桑網(wǎng)站建設(shè)公司，柴桑接單;提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè),網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行柴桑網(wǎng)站開發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

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

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

在被直覺帶入死胡同之后，我們開始調(diào)整調(diào)查的角度：即便一個(gè)鍵本身占用的空間并不大，但是如果相同模式的鍵數(shù)量很多的話，那么合計(jì)起來一樣會(huì)占用大量空間，于是問題就變成了找出哪些相同模式的鍵占用的空間比較大。這次我不想用什么工具，而是打算在測(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：

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)問題了：

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

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

以上是“怎么在Redis里按模式刪除數(shù)據(jù)”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

網(wǎng)站名稱：怎么在Redis里按模式刪除數(shù)據(jù)
文章源于：http://m.jiaotiyi.com/article/jgjigi.html