您当前位于: 首页 » 系统架构设计 » redis中要注意到的Keys模糊搜索导致的性能下降问题

redis中要注意到的Keys模糊搜索导致的性能下降问题03/20/2011

这件事发生在前面我说过的用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的博客(https://timyang.net/)吧,这位高人经常写很牛逼的文章,也包括redis的.

| 10条评论 标签:  

10条评论
  1. KnightE说道:

    keys不能用在生产环境是显然的
    还有sort、xxxUnion、xxxInter等等,跑跑服务马马虎虎,当然也得看量。
    用redis,时刻提醒自己,这是单进程服务!

  2. perfgeeks说道:

    没有照下当时的vmstat真是有点可惜呀

  3. 终小南说道:

    新浪是redis全球最大用户,TimYang是新浪的架构师。自然会牛B一点。

  4. 我亦无情说道:

    切,居然有人在讨论windows下的redis,要知道redis之所以牛逼是因为他在linux下有epoll支持,windows哪行啊?

  5. 神仙说道:

    我的blog搬地方了,链接改一下吧
    xiezhenye.com

  6. 小天说道:

    最近正为这事发愁,感谢博主

  7. TOM说道:

    你是如何解决模糊查询这个问题的?

  8. Zjmainstay说道:

    我也刚刚前天发现并解决了这个问题。但是继续redis做关键词搜索还是没想到好方法,博主有没有建议?

发表评论