动魄惊心的redis keys 事件

最近迅雷9增加游乐场的曝光入口，导致访问量飙升，游乐场首页的心跳接口性能瓶颈立马就体现出来了，心跳里的业务主要包括，小红点提示，在线宝箱，这些都是读写redis操作，今天出现了大量 一台redis 机器大量的连接超时，心跳直接报500 错误，刚开始以为是用户量太大，cup 消耗100%，把redis 搞挂了，但是我门有两台redis机器，另一台机器redis cup 和内存消耗都不高，这就奇怪了？奇怪归奇怪，我们还是马上把心跳接口里的大部分业务下了，下了之后，cup 消耗还是未降下来，神马情况？？？ 后来还是让运维帮忙查看 ，发现有个 keys 命令使用的频繁，其他命令使用率都不高。把keys 命令相关的业务下了之后，cpu 降了！！！。原来是一个同事新上线了一个功能模块，需要匹配某些特别的key 去做推送。

  带着刨根问底的精神，去找了下资料，分析keys 的性能,摘自redis 官方手册的原话

 keys的模糊匹配功能很方便也很强大，但是在生产环境需要慎用！redis的keys 命令导致CPU使用率极高，建议线上禁用keys 命令，那怎么解决这种类似的keys模糊匹配问题呢？其中常见的方法就是设置一个set，将需要使用的keys存储在set中。