Redis过期策略及持久化机制
文章导读目录
|
一、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.aofAOF的工作流程：
（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覆盖掉。
本文使用 文章同步助手 同步
