Redis持久化策略

持久化策略

redis提供2种数据持久化方式：
1、rdb 全量直接持久化
2、aof append only file，追加模式持久化

执行 rdb 持久化时, Redis 会fork出一个子进程, 子进程将内存中数据写入到一个紧凑的文件中, 因此它保存的是某个时间点的完整数据。

aof 其实就是将客户端每一次操作记录追加到指定的aof（日志）文件中，在aof文件体积多大时可以自动在后台重写aof文件（期间不影响正常服务，中途磁盘写满或停机等导致失败也不会丢失数据）

配置方式

rdb配置方式

# 每多少秒 数据改变几次 ，每900秒有一个或以上变化就出发持久化
# 满足下面任一条件进行RDB文件生成
#如果线上环境数据量很大时，可以关闭RDB持久化方式 只需要注释下面三个save即可
save 900 1
save 300 10
save 60 10000
#bgsave生成RDB文件出错时是否停止
stop-writes-on-bgsave-error yes
#RDB文件是否采用压缩
rdbcompression yes
#是否对rdb文件校验和校验
#redis 5之后采用CRC64校验方式
rdbchecksum yes
# rdb文件名字
#  目录位置 采用 dir设置
dbfilename dump-6379.rdb
#指定目录路径非文件名
# rdb文件aof文件均采用此目录
dir ./

aof配置方式

#是否启用AOF持久化方式
appendonly no
#AOF文件名
#目录受Dir控制
appendfilename "appendonly-6379.aof"
#AOF持久化策略
#默认值 everysec
# 有三种 no everysec always
#no        写文件的操作交由操作系统控制
#always    只要缓冲区有数据 立马写入文件中
#everysec  每隔一秒将数据从缓冲区写入文件中
appendfsync everysec
#aof重写期间主进程是否继续讲日志从缓冲区刷新到旧日志文件(上图aof_buf-<旧aof文件)
no-appendfsync-on-rewrite no

#以下两个配置同时满足即可触发AOF重写
#文件增长率
auto-aof-rewrite-percentage 100
#aof重写需要的文件
auto-aof-rewrite-min-size 64mb

混合配置

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。AOF在重写(aof文件里可能有太多没用指令，所以aof会定期根据内存的最新数据生成aof文件)时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起，都写入新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换；
AOF根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof重写AOF。 于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

#redis 4.0引入
# 是否开启混合持久化
aof-use-rdb-preamble yes

重启时Redis使用哪种方式恢复数据 

如果redis宕机或重启时想要恢复数据,会优先采用哪种方式恢复数据呢？
AOF与RDB同时开启时,会优先使用AOF恢复数据,如果采用RDB恢复数据,可以先将AOF关闭,appendonly no,重启完成后，执行config set appendonly yes动态开启AOF

 2种持久化方式对比

rdb 文件二级制格式体积较小，重启恢复速度快
rdb 备份不够及时，可能丢失较多数据
aof 文件体积较大，重启恢复速度较慢
aof 备份数据及时，丢失数据几乎没有