Redis变慢了，快速排查问题方法

很多时候，Redis出现访问延迟变大，都与我们的使用不当或运维不合理导致的。

1、使用复杂度高的命令

首先，查看一下Redis的慢日志。Redis提供了慢日志命令的统计功能，我们通过以下设置，就可以查看有哪些命令在执行时延迟比较大。

首先设置Redis的慢日志阈值，只有超过阈值的命令才会被记录，这里的单位是微妙，例如设置慢日志的阈值为5毫秒，同时设置只保留最近1000条慢日志记录：

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

设置完成之后，所有执行的命令如果延迟大于5毫秒，都会被Redis记录下来，我们执行SLOWLOG get 5查询最近5条慢日志：

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间
   3) (integer) 5299        # 执行耗时(微妙)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list_2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "book_price_1000"
...

通过查看慢日志记录，我们就可以知道在什么时间执行哪些命令比较耗时，如果业务经常使用O(n)以上复杂度的命令，例如sort、sunion、zunionstore，或者在执行O(n)命令时操作的数据量比较大，这些情况下Redis处理数据时就会很耗时。

如果服务请求量并不大，但Redis实例的CPU使用率很高，很有可能是使用了复杂度高的命令导致的。
解决方案就是，不使用这些复杂度较高的命令，并且一次不要获取太多的数据，每次尽量操作少量的数据，让Redis可以及时处理返回。

2、存储大key

如果查询慢日志发现，并不是复杂度较高的命令导致的，例如都是SET、DELETE操作出现在慢日志记录中，那么你就要怀疑是否存在Redis写入了大key的情况。

Redis在写入数据时，需要为新的数据分配内存，当从Redis中删除数据时，它会释放对应的内存空间。

如果一个key写入的数据非常大，Redis在分配内存时也会比较耗时。同样的，当删除这个key的数据时，释放内存也会耗时比较久。

你需要检查你的业务代码，是否存在写入大key的情况，需要评估写入数据量的大小，业务层应该避免一个key存入过大的数据量。

那么有没有什么办法可以扫描现在Redis中是否存在大key的数据吗？

Redis也提供了扫描大key的方法：

redis-cli -h $host -p $port --bigkeys -i 0.01

使用上面的命令就可以扫描出整个实例key大小的分布情况，它是以类型维度来展示的。

需要注意的是当我们在线上实例进行大key扫描时，Redis的QPS会突增，为了降低扫描过程中对Redis的影响，我们需要控制扫描的频率，使用-i参数控制即可，它表示扫描过程中每次扫描的时间间隔，单位是秒。

使用这个命令的原理，其实就是Redis在内部执行scan命令，遍历所有key，然后针对不同类型的key执行strlen、llen、hlen、scard、zcard来获取字符串的长度以及容器类型(list/dict/set/zset)的元素个数。

而对于容器类型的key，只能扫描出元素最多的key，但元素最多的key不一定占用内存最多，这一点需要我们注意下。不过使用这个命令一般我们是可以对整个实例中key的分布情况有比较清晰的了解。

针对大key的问题，Redis官方在4.0版本推出了lazy-free的机制，用于异步释放大key的内存，降低对Redis性能的影响。即使这样，我们也不建议使用大key，大key在集群的迁移过程中，也会影响到迁移的性能

解决方案：尽量少存储大key

3、集中过期

有时你会发现，平时在使用Redis时没有延时比较大的情况，但在某个时间点突然出现一波延时，而且报慢的时间点很有规律，例如某个整点，或者间隔多久就会发生一次。
如果出现这种情况，就需要考虑是否存在大量key集中过期的情况。
如果有大量的key在某个固定时间点集中过期，在这个时间点访问Redis时，就有可能导致延迟增加。

Redis的过期策略采用主动过期+懒惰过期两种策略：

主动过期：Redis内部维护一个定时任务，默认每隔100毫秒会从过期字典中随机取出20个key，删除过期的key，如果过期key的比例超过了25%，则继续获取20个key，删除过期的key，循环往复，直到过期key的比例下降到25%或者这次任务的执行耗时超过了25毫秒，才会退出循环

懒惰过期：只有当访问某个key时，才判断这个key是否已过期，如果已经过期，则从实例中删除

注意，Redis的主动过期的定时任务，也是在Redis主线程中执行的，也就是说如果在执行主动过期的过程中，出现了需要大量删除过期key的情况，那么在业务访问时，必须等这个过期任务执行结束，才可以处理业务请求。此时就会出现，业务访问延时增大的问题，最大延迟为25毫秒。
而且这个访问延迟的情况，不会记录在慢日志里。慢日志中只记录真正执行某个命令的耗时，Redis主动过期策略执行在操作命令之前，如果操作命令耗时达不到慢日志阈值，它是不会计算在慢日志统计中的，但我们的业务却感到了延迟增大。
此时你需要检查你的业务，是否真的存在集中过期的代码，一般集中过期使用的命令是expireat或pexpireat命令，在代码中搜索这个关键字就可以了。
解决方案是，在集中过期时增加一个随机时间，把这些需要过期的key的时间打散即可。

解决方案是，在集中过期时增加一个随机时间，把这些需要过期的key的时间打散即可。

# 在过期时间点之后的5分钟内随机过期掉
redis.expireat(key, expire_time + random(300))

4、实例内存达到上限

有时我们把Redis当做纯缓存使用，就会给实例设置一个内存上限maxmemory，然后开启LRU淘汰策略。

当实例的内存达到了maxmemory后，你会发现之后的每次写入新的数据，有可能变慢了。

导致变慢的原因是，当Redis内存达到maxmemory后，每次写入新的数据之前，必须先踢出一部分数据，让内存维持在maxmemory之下。

这个踢出旧数据的逻辑也是需要消耗时间的，而具体耗时的长短，要取决于配置的淘汰策略：

allkeys-lru：不管key是否设置了过期，淘汰最近最少访问的key volatile-lru：只淘汰最近最少访问并设置过期的key
allkeys-random：不管key是否设置了过期，随机淘汰 volatile-random：只随机淘汰有设置过期的key
allkeys-ttl：不管key是否设置了过期，淘汰即将过期的key noeviction：不淘汰任何key，满容后再写入直接报错
allkeys-lfu：不管key是否设置了过期，淘汰访问频率最低的key（4.0+支持）
volatile-lfu：只淘汰访问频率最低的过期key（4.0+支持）

具体使用哪种策略，需要根据业务场景来决定。

我们最常使用的一般是allkeys-lru或volatile-lru策略，它们的处理逻辑是，每次从实例中随机取出一批key（可配置），然后淘汰一个最少访问的key，之后把剩下的key暂存到一个池子中，继续随机取出一批key，并与之前池子中的key比较，再淘汰一个最少访问的key。以此循环，直到内存降到maxmemory之下。

如果使用的是allkeys-random或volatile-random策略，那么就会快很多，因为是随机淘汰，那么就少了比较key访问频率时间的消耗了，随机拿出一批key后直接淘汰即可，因此这个策略要比上面的LRU策略执行快一些。

但以上这些逻辑都是在访问Redis时，真正命令执行之前执行的，也就是它会影响我们访问Redis时执行的命令。

另外，如果此时Redis实例中有存储大key，那么在淘汰大key释放内存时，这个耗时会更加久，延迟更大，这需要我们格外注意。

如果你的业务访问量非常大，并且必须设置maxmemory限制实例的内存上限，同时面临淘汰key导致延迟增大的的情况，要想缓解这种情况，除了上面说的避免存储大key、使用随机淘汰策略之外，也可以考虑拆分实例的方法来缓解，拆分实例可以把一个实例淘汰key的压力分摊到多个实例上，可以在一定程度降低延迟。

5、fork耗时严重

如果你的Redis开启了自动生成RDB和AOF重写功能，那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大，而等这些任务执行完毕后，延迟情况消失。
遇到这种情况，一般就是执行生成RDB和AOF重写任务导致的。

生成RDB和AOF都需要父进程fork出一个子进程进行数据的持久化，在fork执行过程中，父进程需要拷贝内存页表给子进程，如果整个实例内存占用很大，那么需要拷贝的内存页表会比较耗时，此过程会消耗大量的CPU资源，在完成fork之前，整个实例会被阻塞住，无法处理任何请求，如果此时CPU资源紧张，那么fork的时间会更长，甚至达到秒级。这会严重影响Redis的性能。

我们可以执行info命令，查看最后一次fork执行的耗时latest_fork_usec，单位微妙。这个时间就是整个实例阻塞无法处理请求的时间。

除了因为备份的原因生成RDB之外，在主从节点第一次建立数据同步时，主节点也会生成RDB文件给从节点进行一次全量同步，这时也会对Redis产生性能影响。

解决方案，我们需要规划好数据备份的周期，建议在从节点上执行备份，而且最好放在低峰期执行。如果对于丢失数据不敏感的业务，那么不建议开启AOF和AOF重写功能。