redis过期策略及持久化机制_redistemplate设置key有效期

一、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提供了RDB和AOF两种持久化机制，即把数据保存到磁盘。

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
1
2
3
4
5
6

AOF的工作流程：

（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覆盖掉。