redis查询慢，你们是如何排查优化的？（运维篇5）

1、实例内存达到上限

如果你的 Redis 实例设置了内存上限 maxmemory，那么也有可能导致 Redis 变慢。

当我们把 Redis 当做纯缓存使用时，通常会给这个实例设置一个内存上限 maxmemory，然后设置一个数据淘汰策略。

而当实例的内存达到了 maxmemory 后，你可能会发现，在此之后每次写入新数据，操作延迟变大了。

Why？这是为什么？

原因在于，当 Redis 内存达到 maxmemory 后，每次写入新的数据之前，Redis 必须先从实例中踢出一部分数据，让整个实例的内存维持在 maxmemory 之下，然后才能把新数据写进来。 

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

• allkeys-lru：不管 key 是否设置了过期，淘汰最近最少访问的 key

• volatile-lru：只淘汰最近最少访问、并设置了过期时间的 key

• allkeys-random：不管 key 是否设置了过期，随机淘汰 key

• volatile-random：只随机淘汰设置了过期时间的 key

• allkeys-ttl：不管 key 是否设置了过期，淘汰即将过期的 key

• noeviction：不淘汰任何 key，实例内存达到 maxmeory 后，再写入新数据直接返回错误

• allkeys-lfu：不管 key 是否设置了过期，淘汰访问频率最低的 key（4.0+版本支持）

• volatile-lfu：只淘汰访问频率最低、并设置了过期时间 key（4.0+版本支持）

2、具体使用哪种策略，我们需要根据具体的业务场景来配置。

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

需要注意的是，Redis 的淘汰数据的逻辑与删除过期 key 的一样，也是在命令真正执行之前执行的，也就是说它也会增加我们操作 Redis 的延迟，而且，写 OPS 越高，延迟也会越明显。 

 

另外，如果此时你的 Redis 实例中还存储了 bigkey，那么在淘汰删除 bigkey 释放内存时，也会耗时比较久。

看到了么？bigkey 的危害到处都是，这也是前面我提醒你尽量不存储 bigkey 的原因。

 3、怎么办？ 

1. 避免存储 bigkey，降低释放内存的耗时

2. 淘汰策略改为随机淘汰，随机淘汰比 LRU 要快很多（视业务情况调整）

3. 拆分实例，把淘汰 key 的压力分摊到多个实例上

4. 如果使用的是 Redis 4.0 以上版本，开启 layz-free 机制，把淘汰 key 释放内存的操作放到后台线程中执行（配置 lazyfree-lazy-eviction = yes）