Redis持久化、缓存淘汰策略

Redis持久化

由于Redis数据是存在于缓存中的，如果电脑断电且不开启持久化，则缓存数据全部丢失，因此Redis需要将缓存数据持久化。

RDB持久

RDB持久化只在指定的时间间隔内将内存中的数据快照写入磁盘，当开启redis后，会将快照文件直接读到内存里。

• 在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
• 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次 数据集。 比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次 数据集
• save 60 1000:关闭RDB只需要将所有的RDB保存策略注释掉即可；
• 可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件， 每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

手动save持久化

Redis使用save命令进行持久化，这个过程是同步操作的，直接使用Redis的单线程那一时刻的数据快照存储磁盘文件dump.rdb中，如果数据量过大，这个过程会需要比较长的时间，这样如果用户的Redis请求发送过来时，由于线程被用于持久化，会长时间阻塞，就会使用户产生卡顿的感觉。

手动bgsave持久化过程

借助操作系统提供的写时复制技术，在生成快照的同时，又可以正常处理读写命令。redis会单独创建（fork）一个子进程，共享主线程的所有内存数据，子进程会先将数据写入到一个文件中，待持久化过程结束了，在用这个临时文件替换上次持久化好的RDB文件。
同时、用户发送Redis读操作，主线程对数据也是读操作，则主线程与bgsave相互不影响。
但是，如果主线程要修改一块数据，那么就会复制一份数据，生成该数据的副本，然后，子进程就会把这个副本数据写入RDB文件中，因此，这个过程中，主线程依旧可修改原来的数据。

注：fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

save与bgsave对比

配置自动生成rdb文件后台使用的是bgsave方式。

save 900 1
#若300秒到900秒内，至少有1个key被修改，则触发持久化
save 300 10
#若60秒到300内，至少有10个key被修改，则触发持久化
save 60 10000
#在60秒内至少有10000个key被修改，则触发
#默认开启，开启则会增加CPU开销，但会减小持久化文件大小
dbfilename dump.rdb
#RDB持久化文件名：默认 dump.db
dir ./

AOP（append-only file）

AOF持久化以日志的形式来记录每个写操作，将redis执行过的所有写命令记录下来，只需追加AOF文件。

例如set zhuge 666,aof文件会记录如下数据

*3
$3
set
$5
zhuge
$3
666

• 星号后的数字代表有多少个参数；
• $后的数字代表这个参数值有多少个字符；

如果执行带过期时间的set命令，aof文件里记录的是并不是执行的原始命令，而是记录key过期的时间戳

*3
$3
set
$6
tuling
$3
888
*3
$9
PEXPIREAT
$6
tuling
$13
1604249786301

AOF持久化配置

appendonly no
#是否开启AOF持久化，默认关闭
appendfilename "appendonly.aof"
#配置AOF文件名称，默认为appendonly.aof
# appendfsync always
#持久化策略always模式，总是写入aof文件，并完成磁盘同步，、
性能较差但数据完整性比较好
appendfsync everysec
#持久化策略everysec模式，每一秒写入aof文件，并完成磁盘同步
#如果1秒内宕机，则丢失最后一秒的数据。
# appendfsync no
#持久化策略no模式，写入aof文件，不等待磁盘同步，速度最快

#----------------------下面是重写参数设置-------------------------
#当aof文件大小超过上一次重写的aof文件大小的指定百分比时进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。
auto-aof-rewrite-percentage 100
#允许重写的最小aof文件大小
auto-aof-rewrite-min-size 64mb

• 当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF。
• AOF的重写，Redis会fork一个子进程去做（类似bgsave），不会对redis正常命令处理有太大的影响；

AOF与RDB

RDB模式下，如果Redis服务器挂了，那么就会丢失最后一次备份的数据，可能会丢失几秒、几十秒、甚至几分钟的数据。
AOP模式下，如果Redis服务器挂了，如果开启每一秒备份一次，那么只会丢失最后一秒的数据。
对比之下，AOF比RDB备份的数据更完整。

生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof 一般来说数据更全一点

Redis服务挂了，重启恢复数据

如果RDB与AOF同时开启、那么Redis启动时，会自动读取dir目录下的appendfilename名称的AOF文件，读取AOF文件命令执行恢复数据。
如果没有AOF文件，则读取dir目录下dbfilename名称的RDB文件。

Redis4.0 混合持久化

• 重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。
• 我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很 长的时间。
• Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

通过如下配置可以开启混合持久化(必须先开启aof)：

# aof‐use‐rdb‐preamble yes

如果开启了混合持久化，在AOF重写时，不再将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改 名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

• 混合持久化AOF文件结构如下
  

Redis数据备份策略

1. 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48 小时的备份
2. 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
3. 每次copy备份的时候，都把太旧的备份给删了
4. 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏

缓存删除策略

redis默认内存多少可以用？

如何修改redis内存设置？
通过修改文件配置：maxmemory

通过命令修改：

定时删除

Redis将刚好过期的key删除，可以保证数据的新鲜度，但是这明显不现实，因为这需要Redis时时刻刻去遍历所有的key有效时间，然后进行删除，如果数据量大，将遍历的key的时间本身就耗费很大的时间，CPU忙着遍历，而不是集中精力去处理用户发来的Redis请求。

这种方式以处理器性能换取存储空间。（时间换空间）

惰性删除

• 数据到达过期时间，不做处理，等到下次访问该数据时，检测一下数据是否过期，没过期则返回数据，过期则删除数据，返回不存在。

• 缺点就是如果大量数据过期了，又不会被再次访问，那么就会一直占用内存空间，不会删除，这使可用内存大大减少。

• 这种方式以空间换时间。

定期删除

• 每隔一段时间执行一次删除过期键操作（抽取部分key），通通过限制删除操作时间和频率来减少删除操作对CPU的影响。
• 这个时间的设置如果太短，就会退化为定时删除、太长则删除的key太少，大部分过期key存留，退化为惰性删除。
• 难点就是时长的设置。

内存淘汰策略

• noeviction: 不会驱逐任何key
• volatile-ttl: 删除马上要过期的key
• allkeys-lru: 对所有key使用LRU算法进行删除
• volatile-lru: 对所有设置了过期时间的key使用LRU算法进行删除
• allkeys-random: 对所有key随机删除
• volatile-random: 对所有设置了过期时间的key随机删除
• allkeys-lfu: 对所有key使用LFU算法进行删除
• volatile-lfu: 对所有设置了过期时间的key使用LFU算法进行删除

2个维度：过期键中筛选、所有键中筛选
3个方面：LRU，LFU，random
2个特例：ttl与noeviction;

最常用的是：allkeys-lru策略；

配置与修改

方式一：使用配置文件

方式二：使用命令

config set maxmemory-policy allkeys-lru