Redis学习：Redis的持久化

Redis的持久化方式有两种：rdb和aof
rdb理解为快照，save规则出发会的得到一个快照
aof是追加的形式，可以理解为binlog那种

RDB

在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，主线程会 fork 一个子线程来完成该操作；

• Redis 调用forks。同时拥有父进程和子进程。
• 子进程将数据集写入到一个临时 RDB 文件中。
• 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。)

触发机制

• save的规则满足的情况下，会自动触发rdb原则
• 执行flushall命令，也会触发我们的rdb原则
• 退出redis，也会自动产生rdb文件

使用 save 命令，会立刻对当前内存中的数据进行持久化 ,但是会阻塞，也就是不接受其他操作了；
flushall 命令也会触发持久化 ；
bgsave 是异步进行，进行持久化的时候，redis 还可以将继续响应客户端请求 ；

bgsave和save对比

优点：

适合大规模的数据恢复
对数据的完整性要求不高
缺点：

需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次修改的数据就没有了。
fork进程的时候，会占用一定的内容空间。

AOF

Append Only File

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

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

使用AOF
appendonly yes

appendonly no yes则表示启用AOF

默认是不开启的，我们需要手动配置，然后重启redis，就可以生效了！

如果这个aof文件有错位，这时候redis是启动不起来的，我需要修改这个aof文件

redis给我们提供了一个工具redis-check-aof --fix
优点

每一次修改都会同步，文件的完整性会更加好
没秒同步一次，可能会丢失一秒的数据
从不同步，效率最高
缺点

相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢！
Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持

RDB与AOF对比选择

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。