持久化

场景

如果redis没有对数据进行持久化的话，那么由于redis是将数据保存在内存中的，如果redis发生宕机时会使缓存数据丢失，由于启动redis之后数据丢失无法恢复，那么会导致缓存找不到直接访问数据库，如果数据库访问量过大时会产生缓存雪崩的问题。

RDB快照

根据配置文件的规则，将redis中的所有内存中的数据保存成一个后缀名称为rdb的二进制文件
可以在redis.conf添加以下配置

save 60 10

这个配置表示如果redis在60秒中内被更改了10次，那么生成一个RDB快照。操作redis十次之后，等待一些时间，可以看到目录下有个RDB文件

RDB快照的缺点是冗余丢数据，如果是一直没有触发RDB规则则不会持久化数据到硬盘中，如果这时Redis宕机的话，那么数据就会被丢失。

手动执行命令生成RDB快照文件

save: 以同步的方式将内存中的数据进行持久化保存到硬盘中，在保存的过程中会对其他redis指令进行阻塞，优点是不会占用额外内存。
bgsave: 以异步的方式将内存中的数据持久化到内存中，在保存时会fork一个进程用于保存持久化内存数据，在fork进行时会短暂的阻塞，优点是不会阻塞内存，缺点需要消耗额外内存，在持久化的过程中会新建一个RDB快照文件，持久化的数据是执行bgsave前内存的数据，在执行过程中如果有新的redis指令执行了，那么还会同步写到fork进行的RDB文件中，当fork进行持久化数据完毕就会将新的RDB文件覆盖旧的RDB文件。

缺点

由于没有触发RDB快照规则，这时候redis服务器宕机了，那么数据会发生丢失。如果将RDB快照的规则阈值设置过低，频繁的对内存数据进行操作则会使性能下降。

AOF

会根据的命令生成一个AOF文件，数据在恢复时直接执行AOF的命令就能对数据进行恢复。
开启AOF功能

appendonly yes

AOF策略：

# 每执行一条命令就将命令持久化到AOF文件中 数据安全但性能低
appendfsync always
# 每秒持久化一次 在宕机时会最多丢失一秒的数据
appendfsync everysec
# 从不sync 有操作系统来处理，很不安全
appendfsync no

一般使用appendfsync everysec，即兼顾了性能有兼顾了安全。
有以下命令

set a 1
set a 2
set a 3
set a 4

使用AOF进行数据恢复时会逐条执行以上四条语句，在执行时，前三条并没什么卵用，反正最后一条会更新成4，AOF提供了一种优化机制，通过配置策略来对使AOF文件进行重写，例如我们之前的例子就是会将前三条set删掉，恢复时只执行第四条set就行了。
重写策略如下：

# 文件每增加100%执行一次AOF重写
auto-aof-rewrite-percentage 100
# AOF文件64MB大小时执行AOF文件重写
auto-aof-rewrite-min-size 64mb

文件太小时每必要时AOF重写，因为AOF在后台执行重写时也会消耗性能，太小了没必要，直接就能将数据很快的加载进去。

bgwriteaof可以使用命令对aof文件进行重写。

如果AOF文件和RDB文件同时存在，那么redis会优先使用AOF文件进行恢复，因为AOF数据会更安全些。

混合持久化

采用RDB和AOF混合的方式进行持久化，没执行一条命令会将命令保存到AOF文件中，之后根据之前的AOF重写策略对AOF文件进行重放并将命令转换为二进制，这样一来即兼顾了AOF的数据安全性，有兼顾了RDB文件加载速度快的优点。
必须开启AOF，可以关闭RDB

aof-use-rdb-preamble yes

RDB备份策略

• 根据cronlab每隔一段时间备份一份aof和rdb文件。
• 隔段时间删一遍太旧的数据。
• 可以将数据冗余到别的机器上，避免机器损坏。