redis 持久化

redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 redis 提供了持久化功能
rdb 和 aof 可以同时开启，两种开启的时候，优先载入aof

rdb

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 Snapshot快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建（fork）—个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行仼何IO操作的。这就确倸了极髙的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置

有时候在生产环境会对 .rdb 文件进行一个备份，因为一旦 .rdb 文件丢了就完了，所以最好进行备份
rdb文件根据redis配置文件的 dbfilename 项进行配置，默认为 dump.rdb

在主从复制中，rdb 就是用来备用的，在从机上

rdb 触发机制

1、save 的规则满足的情况下，会自动触发rdb规则，生成 .rdb 文件
2、执行 flushall 命令，也会自动触发rdb规则，生成 .rdb 文件
3、退出redis也就是关机redis或者说是关闭redis服务，也会自动触发rdb规则，生成 .rdb 文件

恢复rdb文件

只需要把 rdb 文件放在 redis 启动目录下就可以了，redis 启动的时候就会自动检查 rdb 文件,恢复其中的数据。查看启动目录，在redis-cil 命令行中输入 config get dir 进行查看

rdb优点

1、适合大规模的数据恢复
2、对数据完整性要求不高

rdb缺点

1、需要一定的时间间隔进程操作,如果意外宕机，最后一次修改的数据就丢失了
2、fork 进程的时候，会占用一定的内存空间，需要考虑内存空间问题

AOF

将我们所有的命令全部都记录下来，history，恢复的时候就再把这个文件全部再执行一遍

以日志的形式来记录每个写操作，将 Redis 执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件， redis 启动之初会读取该文件重新构建数据，换言之， redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

aof 的文件名配置在 redis 配置文件中的 appendfilename 选项，默认为 appendonly.aof
默认 aof 是不开启的 ，默认是每一秒钟执行一次 fsync，也就是持久化，但是每一秒执行一次的话，有可能会导致丢失这一秒的数据

aof 文件有问题的时候，可以通过 redis-check-aof --fix 来修复

aof重写规则

# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，
# 执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。
# 如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，
# 这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,
# 等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据
no-appendfsync-on-rewrite no

# aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，
# 即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程
auto-aof-rewrite-percentage 100
 
# 设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

aof优点

1、每一次修改都同步，文件的完整性会更好
2、每一秒同步一次 ，有可能会一秒的数据
3、从不同步，效率最高，这个自己手动进行同步

aof缺点

1、相对于数据文件来说，aof 远远大于 rdb，修复的速度也比 rdb慢
2、aof 是个读写的操作，IO操作，运行的效率也要比rdb慢，所以redis默认的配置是rdb持久化