【Redis】数据过期策略和数据淘汰策略

数据过期策略和淘汰策略

过期策略

Redis所有的数据结构都可以设置过期时间,时间一到,就会自动删除。

问题:大家都知道,Redis是单线程的,如果同一时间太多key过期,Redis删除的时间也会占用线程的处理时间,如果删除的太过于频繁,会不会导致线上读写指令出现卡顿?

这些问题Redis作者 Antirez 早就想到了,所以在过期这件事上,Redis非常小心 。

两种删除策略:

  • 定时扫描策略:集中处理
  • 惰性删除策略:零散处理

定时扫描策略

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

具体流程:

Redis默认会每秒进行十次过期扫描,过期扫描不会遍历过期字典中所有的key,而是采用了一种简单的贪心策略。

  1. 从过期字典中随机选择20个key
  2. 删除这20个key中已经过期的key
  3. 如果过期的key比率超过1/4,那就重复步骤1

同时,为了保证过期扫描不会出现循环过度,导致线程卡死现象,算法还增加了扫描时间的上限,默认不会超过25ms

问题:设想一个大型的Redis实例中所有的key在同一时间过期了,会出现怎样的结果?

毫无疑问,Redis会持续扫描过期字典(循环多次),直到过期字典中过期的 key 变得稀疏,才会停止(循环次数明显下降)。这就会导致线上读写请求出现明显卡顿现象。导致这种卡顿的另外一种原因是内存管理器需要频繁回收内存页,这也会产生一定的CPU消耗。

但是我们不是已经有25ms的时间上限了么,怎么会导致卡顿呢?

eg :
假如有101个客户端同时将请求发过来了,然后前100个请求的执行时间都是25ms,那么第101个指令需要等待多久才能执行?

答案:2500ms,这个就是客户端的卡顿时间,是由服务器不间断的小卡顿积少成多导致的。

所以业务开发人员一定要注意过期时间,如果有大批量的key过期,要给过期时间设置一个随机范围,而不能全部在同一时间过期。

在目标过期时间上增加一天的随机时间

redis.expire_at(key, random.randint(86400) + expire_ts)

优点:可以保证过期key会被尽快删除,也就是内存可以尽快地被释放。因此,定时删除策略对内存来说是比较友好的。

缺点:在过期key比较多的情况下,删除过期key可能会占用相当一部分CPU时间,在内存不紧张但CPU时间紧张的情况下,将CPU时间用于删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响。所以,定时删除策略对CPU不友好。

惰性删除策略

惰性删除策略就是在客户端访问这个key的时候,redis对key的过期时间进行检查,如果过期了就立即删除。

优点:因为每次访问时,才会检查key是否过期,所以此策略只会使用很少的系统资源,因此,惰性删除策略会节约CPU性能。

缺点:内存压力很大,出现长期占用内存的数据。

淘汰策略

上面说的过期删除策略,是删除已过期的key,而当Redis的运行内存已经超过Redis设置的最大内存之后,则会使用内存淘汰策略删除符合条件的key,以此来保障Redis高效的运行。

如何设置Redis最大运行内存?

在配置文件redis.conf中,可以通过参数maxmemory 来设定最大运行内存,只有在Redis的运行内存达到了我们设置的最大运行内存,才会触发内存淘汰策略。不同位数的操作系统,maxmemory的默认值是不同的。

  • 在64位操作系统中,maxmemory的默认值是0,表示没有内存大小限制,那么不管用户存放多少数据到Redis中,Redis也不会对可用内存进行检查,直到Redis实例因内存不足而崩溃也无作为。
  • 在32位操作系统中,maxmemory的默认值是3G,因为32位的机器最大只支持4GB的内存,而系统本身就需要一定的内存资源来支持运行,所以32位操作系统限制最大 3GB 的可用内存是非常合理的,这样可以避免因为内存不足而导致Redis实例崩溃。

Redis内存淘汰策略有哪些?

不进行数据淘汰的策略

noeviction(Redis3.0之后,默认的内存淘汰策略):它表示当运行内存超过最大设置内存时, 不淘汰任何数据,这时如果有新的数据写入,会报错通知禁止写入,不淘汰任何数据,但是如果没用数据写入的话,只是单纯的查询或者删除操作的话,还是可以正常工作。

进行数据淘汰的策略

在设置了过期时间的数据中进行淘汰:

  • valatile-random:随机淘汰了设置了过期时间的任意键值
  • volatile-ttl:优先淘汰更早过期的键值
  • volatile-lru(Redis3.0之前,默认的内存淘汰策略):淘汰所有设置了过期时间的键值中,最久未使用的键值;
  • volatile-lfu(Redis4.0后新增的内存淘汰策略):淘汰所有设置了过期时间的键值中,最少使用的键值。

在所有数据范围内进行淘汰:

  • allkeys-random:随机淘汰任意键值
  • allkeys-lru:淘汰整个键值中最久未使用的键值
  • allkeys-lfu(Redis 4.0 后新增的内存淘汰策略):淘汰整个键值中最少使用的键值。
如何修改Redis内存淘汰策略?

设置内存淘汰策略的两种方法:

  • 方式一:通过config set maxmemory-policy <策略>命令设置。它的优点是设置之后立即生效,不需要重启Redis服务,缺点是重启Redis之后,设置就会失效。
  • 方式二:通过修改Redis配置文件修改,设置maxmemory-policy <策略>,它的优点是重启Redis服务后配置不会丢失,缺点是必须重启Redis服务,设置才能生效。
LRU算法和LFU算法有什么区别?

什么是LRU算法?

LRU 全称是 Least Recently Used翻译为最近最少使用,会选择淘汰最近最少使用的数据。

传统的 LRU 算法的实现是基于【链表】结构,链表中的元素按照操作顺序从前往后排列,最新操作的键会被移动到表头,当需要内存淘汰时,只需要删除链表尾部的元素即可,因为链表尾部的元素就代表最久未被使用的元素。

Redis并没有使用这样的方式实现LRU算法,因为传统的LRU算法存在两个问题:

  • 需要用链表管理所有的缓存数据,这会带来额外的空间开销;
  • 当有数据被访问时,需要在链表上把该数据移动到头端,如果有大量数据被访问,就会带来很多链表移动操作,会很耗时,进而会降低Redis缓存性能。

Redis是如何实现LRU算法的?

Redis 实现的是一种近似LRU算法,目的是为了更好的节约内存,它的实现方式是在Redis的对象结构体中添加一个额外的字段,用于记录此数据的最后一次访问时间。

当Redis 进行内存淘汰时,会使用随机采样的方式来淘汰数据,它是随机取 5 个值(个数可配置),然后淘汰最久没有使用的那个

Redis实现的LRU算法的优点:

  • 不用为所有的数据维护一个大链表,节省了空间占用
  • 不用在每次数据访问时都移动链表项,提升了缓存的性能。

但是LRU算法有一个问题,无法解决缓存污染问题,比如应用依次读取了大量的数据,而这些数据只会被读取这一次,那么这些数据会留存在 Redis 缓存中很长一段时间,造成缓存污染,

因此,在Redis 4.0 之后引入了LFU算法来解决这个问题。

什么时LFU算法?

LFU全程是 Least Frequently Used翻译为最近最不常用,LFU算法是根据数据访问次数来淘汰数据的,它的核心思想是“如果数据过去被访问多次,那么将来被访问的频率也更高”

所以,LFU算法会记录每个数据的访问次数。当一个数据被再次访问时,就会增加该数据的访问次数。这样就解决了偶尔被访问一次之后,数据留存在缓存中很长一段时间的问题,相比于LRU算法也更合理一些。

实现:

typedef struct redisObject {
    ...
      
    // 24 bits,用于记录对象的访问信息
    unsigned lru:24;  
    ...
} robj;

Redis 对象头中的 lru 字段,在 LRU 算法下和 LFU 算法下使用方式并不相同。

LRU 算法中,Redis 对象头的 24 bits 的 lru 字段是用来记录 key 的访问时间戳,因此在 LRU 模式下,Redis可以根据对象头中的 lru 字段记录的值,来比较最后一次 key 的访问时间长,从而淘汰最久未被使用的 key。

LFU 算法中,Redis对象头的 24 bits 的 lru 字段被分成两段来存储,高 16bit 存储 ldt(Last Decrement Time),低 8bit 存储 logc(Logistic Counter)。

【Redis】数据过期策略和数据淘汰策略_第1张图片

  • ldt 是用来记录 key 的访问时间戳;
  • logc 是用来记录 key 的访问频次,它的值越小表示使用频率越低,越容易淘汰,每个新加入的 key 的logc 初始值为 5。

注意,logc 并不是单纯的访问次数,而是访问频次(访问频率),因为 logc 会随时间推移而衰减的

在每次 key 被访问时,会先对 logc 做一个衰减操作,衰减的值跟前后访问时间的差距有关系,如果上一次访问的时间与这一次访问的时间差距很大,那么衰减的值就越大,这样实现的 LFU 算法是根据访问频率来淘汰数据的,而不只是访问次数。访问频率需要考虑 key 的访问是多长时间段内发生的。key 的先前访问距离当前时间越长,那么这个 key 的访问频率相应地也就会降低,这样被淘汰的概率也会更大。

对 logc 做完衰减操作后,就开始对 logc 进行增加操作,增加操作并不是单纯的 + 1,而是根据概率增加,如果 logc 越大的 key,它的 logc 就越难再增加。

所以,Redis 在访问 key 时,对于 logc 是这样变化的:

  1. 先按照上次访问距离当前的时长,来对 logc 进行衰减;
  2. 然后,再按照一定概率增加 logc 的值

redis.conf 提供了两个配置项,用于调整 LFU 算法从而控制 logc 的增长和衰减:

  • lfu-decay-time 用于调整 logc 的衰减速度,它是一个以分钟为单位的数值,默认值为1,lfu-decay-time 值越大,衰减越慢;
  • lfu-log-factor 用于调整 logc 的增长速度,lfu-log-factor 值越大,logc 增长越慢。

你可能感兴趣的:(Redis,redis,数据库,缓存,nosql,非关系型数据库)