Redis持久化---RDB + AOF 入门介绍

RDB： redis database

AOF： append only file

 

RDB

什么是RDB： 在指定的时间间隔内将内存中的数据集快照写入磁盘。也就是行话讲的Snapshot 快照，它恢复时是将快照文件直接写入内存中。

FORK： fork作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

 

查看redis的配置文件

表示：900 秒内 key改动1次，就保存到dump.rdb

          300秒内key改动10次，就保存到dump.rdb

        60秒内key改动10000次，就自动保存到dump.rdb

即：

save 可以自己选择立即保存到dump.rdb

flushall 也可以保存文件

 

如何恢复数据：

需要将dump.rdb进行备份，生成dump_bk.rdb。

在对redis进行flush命令之后，redis会将空数据传给当前的dump.rdb，我们需要删除dump.rdb，然后倒入备份的rdb就可以重新连上之前的数据

部分代码：

注意备份的文件 最后一定放在另外一台机器上、

劣势：备份数据有可能不完整，因为是按一定时间进行备份的，刚好一段时间差一秒可以备份，刚好redis崩了，这个时间端内的数据就没办法保存

 优势：恢复数据快，因为你一导入dump.rdb，瞬间就会转到内存中去执行

RDB之后产生了 AOF

AOF

是什么：以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以修改文件，redis启动之初会读取该文件重新构建数据，redis重启的话就根据日志文件将指令执行一次

 

复制之前的配置文件：

修改为 yes

我们所有的操作都会记录到 appendonly.aof文件中

查看该文件，可以修改，但实际工作中不需要改：

如果你修改了aof文件，添加了非法字符，可以 修复，使用

 

AOF 和 RDB 两种 策略可以共存

aof 保存的是appendonly.aof文件

修改appendonly no ，改为yes

重启redis然后重新加载

 

rewrite：重写机制

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

 

触发机制 ：

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

 

 

劣势：

aof 慢于 rdb

 

两个技术的选择：

 

RDB：快

AOF：全

只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

同时开启两种持久化方式，在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，
因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，
快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。