一个安静的晚上突然被群里报警打断，然后果断不情愿的爬起来找问题，通过监控发现一个服务的QPS暴增，接口响应延迟也上来了，达到s级别了，所以赶紧找问题。
因为应用很依赖redis，第一时间先看是不是它，果然还真是它，看下图：
确定了问题的方向就该找具体原因了，进一步查看Zabbix发现其中一台redis的CPU使用率明显升高，如下图：
连到机器上top发现redis-server的CPU使用率已经达到100%，这里说明一点：Zabbix上显示CPU使用率升高到60%，是因为这里展示的是2个核（redis使用的双核机器）的平均值，而redis是单线程的，处理数据只用到一个CPU。
看到这里就能想到典型的热key问题了，然后通过redis-cli -h shua-kxct-redis008 -p 9720 monitor命令查看问题发生在哪个key上。最终发现查询最多的是头像和昵称的采集key上。
第一步处理是将该处查询redis的地方注掉重新上线，保证线上服务的可用性（这里是非关键业务）
第二步优化：优化也就是对数据进行切分，避免所有操作落在一台机器上，因为采集线上用户的头像和昵称是按天采集，所以key使用的是关联当天的日期，解决方案就是按照用户ID取模进行key关联。