这件事发生在前面我说过的用redis来做一个实时性很强的小功能的时候，准确的说是去年的事情了，之所以没说，是我觉得这个确实是一个很小的问题，现在貌似网上还真没有遇到同类问题的同仁，那我就大胆说说了哈——我们把功能开放给测试用户，只要开放1分钟不到，马上cpu占用100%，其他网络流量、磁盘IO都非常小，因为就开放给几百用户撒，最先怀疑是redis的配置有问题，比如太频繁的写硬盘之类，一项一项的排查，均未发现问题，只能从程序方面着手查了，后来发现我的一处执行了KEYS “MT|*”，是用来获取一个用户动态所有类型key的，实际上当时也就8种类型，也没怎么怀疑到这个上面来，后来查了一圈，实在没有找到地方，因为php跟redis通信就那么几个地方，就怀疑这里了，改成MT|1,MT|2，……一直遍历获取这些key-value，因为有的类型可能该用户没有，所以我开始使用了key的模糊搜索，没想到问题就出在这里了！经此一改，立马见神效，cpu一直维持在4%以下，io和网络流量也都很小，一秒钟大约读写几千条吧，因为我们做了一些限制，不然磁盘文件增长的有些快！这和redis理论值差的远，所以那太高性能、高可用的redis服务器一直运行到现在（3个多月了），从未出现过服务中断的情况。
给力啊，redis!现在还有一个难以解决的问题是，不好清理redis里面的无用内容，只是写了个简单的脚本每天跑一下。缺少一个强有力的工具来管理redis，另外，貌似有人实现了一个用sql语句来查询redis。不知道对管理有效否？最后，推荐下timyang的博客(http://timyang.net/)吧，这位高人经常写很牛逼的文章，也包括redis的.
相关文章
转载请注明：爱开源 » redis中要注意到的Keys模糊搜索导致的性能下降问题