1、首先查后端业务代码。是否有长时间循环，等待临界资源等。
2.网络原因，导致服务器和redis,mysql之间传数据存在高延迟，丢包等现象，运维人员的协助；

3.问题在redis上

先在redis服务器上测试响应延迟， redis -cli --latency(ping出来的），避免网络原因。

分析变慢原因：
慢日志分析： slowlog get 10获取慢日志。看看有哪些操作导致慢。可能原因有以下：

1.使用复杂度过高的命令
redis读很多都是O(1)的，但是范围查询这些是O（N）的，还有大于线性的，比排序等，这导致长时间占用CPU，表现就是ops不高但是CPU使用率很高。解决办法是在客户端把这些事做了。还有就是n很大的话，得花时间在网络传输上。

2.bigkey的影响
如果慢日志存在set/del这种简单的操作，说明可能存在bigkey。 可以查询：redis -cli --bigkeys
这里的bigkey不一定是内存最大，也可能是拥有元素最多。如果键的值太大，那么分配内存和释放内存比较耗时。比如可以采用unlink代替del,后台线程去做，不过最好不要有bigkey。

3集中过期
如果慢日志查询某个时间点，慢操作，有可能是key集中过期了，导致缓存雪崩。解决办法是均匀过期时间。

4.内存不够了
内存不够导致哈希冲突，以及内存淘汰策略。（避免bigkey，淘汰不用LRU，分片集群，释放内存后台完成）
以上都是慢日志可以分析的，下面是别的原因
5、fork耗时严重
AOF重写期间会fork子进程，拷贝页表，如果页表很大，就会消耗大量CPU资源，如果重写期间出现写操作，就会写时复制，在副本上写。

AOF写入磁盘也会有性能问题。