Redis过期策略及持久化机制

  • 作者: 凯哥Java(公众号:凯哥Java)
  • Redis
  • 时间:2023-04-07 16:14
  • 3825人已阅读
简介 一、Redis设置过期时间二、Redis的过期策略1、定时过期2、惰性过期3、定期过期三、Redis的8种内存淘汰策略LRU与LFU四、Redis 的持久化机制1、RDB快照持久化(redis默认)2、AOF追加文件持久化3、AOF和RDB都开启

🔔🔔🔔好消息!好消息!🔔🔔🔔

有需要的朋友👉:联系凯哥 微信号 kaigejava2022

一、Redis设置过期时间  

Redis有四个不同的命令可以用于设置键的生存时间:

  • EXPIRE<key><ttl>命令用于将键key的生存时间设置为ttl秒。

  • PEXPIRE<key><ttl>命令用于将键key的生存时间设置为ttl毫秒。

  • EXPIREAT<key><timestamp>命令用于将键key的过期时间设置为timestamp所指定的秒数时间戳。

  • PEXPIREAT<key><timestamp>命令用于将键key的过期时间设置为timestamp所指定的毫秒数时间戳。

实际上EXPIRE、PEXPIRE、EXPIREAT三个命令都是使用PEXPIREAT命令来实现的。

PERSIST key , 设置key 永不过期。

 二、Redis的过期策略  

1、定时过期  

该策略可以立即清除过期的数据。每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即对key进行清除,对内存很友好,但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。

2、惰性过期  

只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。

3、定期过期  

每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

expires字典会保存所有设置了过期时间的key的过期时间数据,其中,key是指向键空间中的某个键的指针,value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

Redis中同时使用了惰性过期和定期过期两种过期策略

 三、Redis的8种内存淘汰策略  

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时,怎么处理需要新写入且需要申请额外空间的数据。

  • 1)noeviction(默认策略):对于写请求不再提供服务,直接返回错误(DEL请求和部分特殊请求除外)

  • 2)allkeys-lru:从所有key中使用LRU算法进行淘汰

  • 3)volatile-lru:从设置了过期时间的key中使用LRU算法进行淘汰

  • 4)allkeys-random:从所有key中随机淘汰数据

  • 5)volatile-random:从设置了过期时间的key中随机淘汰

  • 6)volatile-ttl:在设置了过期时间的key中,根据key的过期时间进行淘汰,越早过期的越优先被淘汰

  • 7)volatile-lfu:4.0版本新增,当内存不足以容纳新写入数据时,在过期的key中,使用LFU算法进行删除key。

  • 8)allkeys-lfu:4.0版本新增,当内存不足以容纳新写入数据时,从所有key中使用LFU算法进行淘汰;

注: 1)使用volatile-lru、volatile-random、volatile-ttl这三种策略时,如果没有key可以被淘汰,则和noeviction一样返回错误; 2)4.x 后支持LFU策略,最少频率使用 3)redis支持运行时通过命令动态修改内存大小:127.0.0.1:6379> config set maxmemory 100mb

LRU与LFU

LRU(Least recently used,最近最少使用) LRU算法根据数据的历史访问记录来进行淘汰数据,其核心思想是“如果数据最近被访问过,那么将来被访问的几率也更高”。 基本思路 新数据插入到列表头部; 每当缓存命中(即缓存数据被访问),则将数据移到列表头部;当列表满的时候,将列表尾部的数据丢弃。

LFU(Least Frequently Used 最少频率使用) 它是基于“如果一个数据在最近一段时间内使用次数很少,那么在将来一段时间内被使用的可能性也很小”的思路。LFU需要定期衰减。

 四、Redis 的持久化机制

为了避免数据丢失了,Redis提供了RDBAOF两种持久化机制,即把数据保存到磁盘。

1、RDB快照持久化(redis默认)

RDB,就是把内存数据以快照的形式保存到磁盘上。在指定的时间间隔内,执行指定次数的写操作,将内存中的数据集快照写入磁盘中,它是Redis默认的持久化方式。执行完操作后,在指定目录下会生成一个dump.rdb文件,Redis 重启的时候,通过加载dump.rdb文件来恢复数据。

RDB触发机制主要有以下几种:

  • 手动触发(一般不会用): save:同步,会阻塞当前redis服务bgsave :异步,redis进程执行fork操作创建子进程

  • 自动触发:save m n (m秒内数据集存在n次修改,自动触发bgsave)

RDB 的优点:

  • RDB 在恢复大数据集时,速度比 AOF 的恢复速度要快。适合大规模的数据恢复场景,如备份,全量复制等。

  • RDB可以最大化Redis的性能。因为父进程在保存RDB文件时唯一要做的就是fork出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无需执行任何磁盘I/O操作。但是如果数据集比较大的时候,fork可以能比较耗时,造成服务器在一段时间内停止处理客户端的请求。

RDB缺点:

  • 没办法做到实时持久化/秒级持久化。

  • 新老版本存在RDB格式兼容问题

2、AOF追加文件持久化  

AOF(append only file) 持久化,采用日志的形式来记录每个写操作,追加到文件中,重启时再重新执行AOF文件中的命令来恢复数据。它主要解决数据持久化的实时性问题。默认是不开启的。

AOF的优点:

  • 数据的一致性和完整性更高

AOF的缺点:

  • 记录的内容越多,文件越大,数据恢复变慢。

redis可以通过配置项开启AOF机制,如下:

# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
# AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的。
dir ./
# 默认的文件名是appendonly.aof,可以通过appendfilename参数修改
appendfilename appendonly.aof

AOF的工作流程:

2d2e4c11b8b34460db8860224adeee94.png

(1)所有的写入命令会追加(append)到aof_buf(缓冲区)中。 (2)AOF缓冲区根据对应的策略向硬盘做同步(sync)操作。 (3)随着AOF文件越来越大,需要定期对AOF文件进行重写(rewrite),达到压缩的目的。(4)当Redis服务器重启时,可以加载AOF文件进行数据恢复(load)。

3、AOF和RDB都开启

redis允许我们同时使用两种机制,即使AOF和RDB都开启了,redis重启的时候,也是优先通过AOF进行数据恢复的,因为aof数据比较完整。

通常情况下我们会设置AOF机制为everysec 每秒写入,则最坏仅会丢失一秒内的数据。

注:如果先开启了RDB,再开启AOF,RDB先执行了持久化,那么RDB文件中的内容会被AOF覆盖掉。



TopTop