redis过时策略和内存淘汰机制

目录

• 常见的删除策略
• redis使用的过时策略:按期删除+惰性删除
  • 按期删除
  • 惰性删除
  • 为何要采用按期删除+惰性删除2种策略呢？
• redis内存淘汰机制

常见的删除策略

1.定时删除：在设置键的过时时间的同时，建立一个timer，让定时器在键的过时时间到达时，当即执行对键的删除操做。（主动删除）

对内存友好，可是对cpu时间不友好，有较多过时键的而状况下，删除过时键会占用至关一部分cpu时间。

2.惰性删除：听任过时键无论，可是每次从键空间中获取键时，都检查取到的键是否过去，若是过时就删除，若是没过时就返回该键。（被动删除）

对cpu时间友好，程序只会在取出键的时候才会对键进行过时检查，这不会在删除其余无关过时键上花费任何cpu时间，可是若是一个键已通过期，而这个键又保留在数据库中，那么只要这个过时键不被删除，他所占用的内存就不会释放，对内存不友好。

3.按期删除：每隔一段时间就对数据库进行一次检查，删除里面的过时键。（主动删除）

采用对内存和cpu时间折中的方法，每一个一段时间执行一次删除过时键操做，并经过限制操做执行的时长和频率来减小对cpu时间的影响。难点在于，选择一个好的策略来设置删除操做的时长和执行频率。

redis使用的过时策略:按期删除+惰性删除

按期删除

redis 会将每一个设置了过时时间的 key 放入到一个独立的字典中，之后会按期遍历这个字典来删除到期的 key。

Redis 默认会每秒进行十次过时扫描（100ms一次），过时扫描不会遍历过时字典中全部的 key，而是采用了一种简单的贪心策略。

• 从过时字典中随机 20 个 key；
• 删除这 20 个 key 中已通过期的 key；
• 若是过时的 key 比率超过 1/4，那就重复步骤 1；

redis默认是每隔 100ms就随机抽取一些设置了过时时间的key，检查其是否过时，若是过时就删除。注意这里是随机抽取的。为何要随机呢？你想想假如 redis 存了几十万个 key ，每隔100ms就遍历全部的设置过时时间的 key 的话，就会给 CPU 带来很大的负载！

惰性删除

所谓惰性策略就是在客户端访问这个key的时候，redis对key的过时时间进行检查，若是过时了就当即删除，不会给你返回任何东西。

按期删除可能会致使不少过时key到了时间并无被删除掉。因此就有了惰性删除。假如你的过时 key，靠按期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，即当你主动去查过时的key时,若是发现key过时了,就当即进行删除,不返回任何东西.

按期删除是集中处理，惰性删除是零散处理。

为何要采用按期删除+惰性删除2种策略呢？

若是过时就删除。假设redis里放了10万个key，都设置了过时时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过时key上了.

可是问题是，按期删除可能会致使不少过时key到了时间并无被删除掉，那咋整呢？因此就是惰性删除了。这就是说，在你获取某个key的时候，redis会检查一下 ，这个key若是设置了过时时间那么是否过时了？若是过时了此时就会删除，不会给你返回任何东西。

并非key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下

经过上述两种手段结合起来，保证过时的key必定会被干掉。

因此说用了上述2种策略后，下面这种现象就不难解释了：数据明明都过时了，可是还占有着内存

redis内存淘汰机制

可是仅仅经过设置过时时间仍是有问题的。咱们想一下：若是按期删除漏掉了不少过时 key，而后你也没及时去查，也就没走惰性删除，此时会怎么样？若是大量过时key堆积在内存里，致使redis内存快耗尽了。redis是如何解决这个问题呢？ 使用redis 内存淘汰机制。

这个问题可能有小伙伴们遇到过，放到Redis中的数据怎么没了？

由于Redis将数据放到内存中，内存是有限的，好比redis就只能用10个G，你要是往里面写了20个G的数据，会咋办？固然会干掉10个G的数据，而后就保留10个G的数据了。那干掉哪些数据？保留哪些数据？固然是干掉不经常使用的数据，保留经常使用的数据了

redis 提供 6种数据淘汰策略：

• no-eviction：不会继续服务写请求(DEL请求能够继续服务)，读请求能够继续进行。这样能够保证不会丢失数据，可是会让线上的业务不能持续进行。这是默认的淘汰策略。
• volatile-lru：尝试淘汰设置了过时时间的 key，最少使用的 key 优先被淘汰。没有设置过时时间的key不会被淘汰，这样能够保证须要持久化的数据不会忽然丢失。（这个是使用最多的）
• volatile-ttl：跟上面同样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰,即淘汰将要过时的数据.
• volatile-random：从已设置过时时间的数据集（server.db[i].expires）中随机选择数据淘汰
• allkeys-lru：区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不仅是过时的 key 集合。这意味着没有设置过时时间的 key 也会被淘汰。
• allkeys-random：从全体的key集合（server.db[i].dict）中任意选择数据淘汰

配置方式:
maxmemory-policy volatile-lru   #默认是noeviction，即不进行数据淘汰