Redis持久化（RDB和AOF机制）

Redis持久化（优先使用AOF）

Redis是内存数据库，如果不将数据存储在磁盘中，一旦断电数据就消失了。故有两种策略进行保存

AOF实时性更好，主流方案，默认没有开启。开启后，每执行一条更改redis数据的命令，都将该命令写入磁盘的AOF中。

三种AOF方式，

always,每次修改都写入AOF;

everysec,每秒钟同步一次，多个命令一次写入。

no,操作系统决定何时同步。

一、RDB机制

将数据以快照的形式保存在磁盘上

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。默认的文件为dump.rdb

在我们安装了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置。

三种保存dump.rdp的机制

1、save触发方式

阻塞当前 Redis 服务器，直到 RDB 过程完成为止，对于内存比较大的实例会造成长时间阻塞，不建议使用。

2、bgsave触发方式

Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。bgsave 是针对 save 阻塞问题做的优化，因此 Redis 内部所有涉及 RDB 的操作都采用 bgsave 的方式，而 save 方式已经废弃。

3、自动触发

自动触发在redis.conf配置文件中去设置：

①save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

bgsave的工作流程？

① 执行 bgsave 命令，Redis 父进程判断当前是否存在正在执行的子进程，如 RDB/AOF 子进程，如果存在 bgsave 命令直接返回。

② 父进程执行 fork 操作创建子进程，fork 操作过程中父进程会阻塞。

③ 父进程 fork 完成后，bgsave 命令返回并不再阻塞父进程，可以继续响应其他命令。

④ 子进程创建 RDB 文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。

⑤ 进程发送信号给父进程表示完成，父进程更新统计信息。

RDB的优缺点

优点：

• 对数据的完整性要求不高
• 因为主进程不进行任何的IO操作，所以对数据的大规模恢复有着极高的性能，适合全量恢复 ，备份等场景

缺点：

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

二、AOF(Append Only File)

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

将写入命令append（追加）到aof_buf里，然后根据刷盘频率，将aof_buf里的数据刷入aof文件，重启的时候，加载aof文件到缓存，恢复数据；

AOF是什么

默认不开启，需要在配置文件中将no改成yes

aof记录的是操作命令

重启redis

rewrite 重写

当写的aof文件大于64m，太大了！会fork一个新的进程来将我们的文件进行重写！

基于以上两点，只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

AOF的优缺点

优点：

1、每一次修改都同步，文件的完整会更加好！

2、每秒同步一次，可能会丢失一秒的数据

3、从不同步，效率最高的！

缺点：

1、相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢！

2、Aof运行效率也要毕rdb慢，所以我们redis默认的配置就是rdb持久化！