比尔云BierYun--阿里云最新优惠活动
阿里云优惠码丨阿里云代金券

Redis系列之—-Redis的过期设置及淘汰策略

Redis系列之—-Redis的过期设置及淘汰策略

Redis的过期时间机制和内存淘汰策略

Redis的数据是存储在内存中的,而服务器的内存大小是有限制的,除非宕机,否则这些数据会一直存在,对于一些不再使用的key,也应当进行删除,否则会浪费内存空间。而且有些场景需要这种有失效性的数据,比如限时优惠活动、用户session、验证码等。过了一定的时间就需要删除这些数据。为了解决这个问题,Redis提供了可以为这个值设置一个过期的时间功能,当达到这个过期时间后,将这个数据进行删掉来释放内存空间。

一、过期时间机制

redis对存储值的过期处理实际上是针对该值的键(key)处理的,即时间的设置也是设置key的有效时间。Expires字典保存了所有键的过期时间,Expires也被称为过期字段。Redis提供了四种处理策略:

  • EXPIRE 将key的生存时间设置为ttl秒
  • PEXPIRE 将key的生成时间设置为ttl毫秒
  • EXPIREAT 将key的过期时间设置为timestamp所代表的的秒数的时间戳
  • PEXPIREAT 将key的过期时间设置为timestamp所代表的的毫秒数的时间戳

1、2两种方式是设置一个过期的时间段,如处理验证码最常用的策略,设置三分钟或五分钟后失效,把分钟数转换成秒或毫秒存储到redis中。
3、4两种方式是指定一个过期的时间 ,比如优惠券的过期时间是某年某月某日,只是单位不一样。

例如:

127.0.0.1:6379> set messageCode 8223
OK
127.0.0.1:6379> expire messageCode 100
(integer) 1

使用ttl命令查看剩余生命周期:

127.0.0.1:6379> ttl messageCode
(integer) 91

在小于2.1.3的版本里,只能对key设置一次expire。2.1.3和之后的版本里,可以多次对key使用expire命令,更新key的expire time。如果对key使用set或del命令,那么也会移除expire time。
设置了过期时间的key会被在过期后会被删除掉,那么redis是以何种方式删掉的呢?

删除策略

Redis提供了三种不同的删除策略:

  • 定时删除:在设置键的过期时间的时候创建一个定时器,当过期时间到的时候立马执行删除操作,此种方式对 正常业务读写影响较大。
  • 定期删除:redis数据库默认每隔100ms就会进行随机抽取一些设置过期时间的key进行检测,过期则删除。
  • 惰性删除:惰性删除是为了堆定期删除的时候没有被抽取到的key进行删除,当访问这个key的时候,才会删除这个key,所以叫惰性删除。

目前,Redis采用的是惰性删除+定期删除的方案。

二、Redis的内存淘汰策略

前面说到,redis的会对过期的key进行清除,但是如果插入的速度大于清除的速度的话,服务器的内存迟早会满的,这个时候,就需要一种淘汰策略来对内存中的key再进行处理,Redis会根据用户配置的淘汰策略清除无用的key释放来内存空间,redis提供了以下八种中内存淘汰的策略:

  • volatile-lru: 从设置过期时间的数据集中挑选出最近最少使用的数据淘汰。没有设置过期时间的key不会被淘汰,这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失。
  • allkeys-lru:从数据集中挑选最近最少使用的数据淘汰,该策略要淘汰的key面向的是全体key集合,而非过期的key集合。
  • volatile-random:从已设置过期时间的数据集中随机选择数据淘汰
  • allkeys-random:从全体的key集合中任意选择数据淘汰
  • volatile-ttl:除了淘汰机制采用LRU,策略基本上与volatile-lru相似,从设置过期时间的数据集中挑选将要过期的数据淘汰,ttl值越大越优先被淘汰。
  • noeviction:禁止驱逐数据,也就是当内存不足以容纳新入数据时,新写入操作就会报错,请求可以继续进行,线上任务也不能持续进行,采用no-enviction策略可以保证数据不被丢失,这也是系统默认的一种淘汰策略。
  • volatile-lfu:从所有配置了过期时间的键中驱逐使用频率最少的键
  • allkeys-lfu:从所有键中驱逐使用频率最少的键。

这里有个特点,所有的设置的过期了的key的淘汰策略名称都是volatile开头的,这是因为设置了过期时间的key都是属于不稳定的key,这里也是见名知意。

Redis中的LRU与常规的LRU实现并不相同,常规LRU会准确的淘汰掉队头的元素,但是Redis的LRU并不维护队列,只是根据配置的策略要么从所有的key中随机选择N个(N可以配置)要么从所有的设置了过期时间的key中选出N个键,然后再从这N个键中选出最久没有使用的一个key进行淘汰。LRU的最近最少使用实际上并不精确,为了解决这个缺陷,Redis4.0提供了LFU(Least Frequently Used)算法,也就是最频繁被访问的数据将来最有可能被访问到。思想类似redis会每个key维护一个计数器。每次key被访问的时候,计数器增大。计数器越大,可以约等于访问越频繁。

如何设置过期淘汰策略

在redis的redis.conf文件中,有这样一段描述:

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones with an expire set.
# allkeys-random -> Remove a random key, any key.
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
# noeviction -> Don't evict anything, just return an error on write operations.
# LRU是最近最少使用
# LRU means Least Recently Used
# LFU是最少使用
# LFU means Least Frequently Used
#
# Both LRU, LFU and volatile-ttl are implemented using approximated
# randomized algorithms.
#
# Note: with any of the above policies, Redis will return an error on write
#       operations, when there are no suitable keys for eviction.
#
#       At the date of writing these commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort
#
# The default is:
# 默认使用的是noeviction
# maxmemory-policy noeviction

这段配置文件描述的很清楚,只需要看一下便能了解这些配置的含义。

一般来说,volatile-lru使用的场景偏多,在开发中,对于那些重要的,绝对不能丢弃的数据(如配置类数据等),应不设置有效期,这样Redis就永远不会淘汰这些数据;对于那些相对不是那么重要的,并且能够回源的数据,可以设置有效期,这样在内存不够时Redis就会淘汰这部分数据。

设置淘汰策略:
到redis的bin目录下使用如下命令:

redis-cli -p 6379 config set maxmemory-policy volatile-lru

或者直接修改redis.conf配置:

maxmemory-policy volatile-lru

Redis中的淘汰机制是从性能和可用性方面考虑的,并不是完全可靠,我们在开发中应尽量对不需要永久保存的数据主动设置或更新key的expire时间,主动删除这部分数据,提升Redis整体性能和空间。

原文地址https://www.cnblogs.com/JackSparrow-/p/12174069.html

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

强烈推荐

高性能SSD云服务器ECS抗攻击,高可用云数据库RDS