redis的持久化机制

持久化-RDB(Redis Databases)

什么是RDB

 

在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复 ；

默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。文件名可以在配置文件中进行自定义。

工作原理

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

 

1.Redis 调用forks。同时拥有父进程和子进程。

2.子进程将数据集写入到一个临时 RDB 文件中。

3.当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

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

触发机制

 

1. save的规则满足的情况下，会自动触发rdb原则

save:

使用 save 命令，会立刻对当前内存中的数据进行持久化 ,但是会阻塞，也就是不接受其他操作了；

由于 save 命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。

配置持久化规则：

可以通过配置文件对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动进行数据集保存操作。

bgsave：

bgsave 是异步进行，进行持久化的时候，redis 还可以将继续响应客户端请求 ；

bgsave和save对比

2. 执行flushall命令，也会触发我们的rdb原则

3. 退出redis，也会自动产生rdb文件

RDB持久化的优缺点

 

优点：

适合大规模的数据恢复

对数据的完整性要求不高

 

缺点：

需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次修改的数据就没有了。

fork进程的时候，会占用一定的内容空间。

持久化-AOF(Append Only File)

 

快照功能（RDB）并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、以及未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

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

开启AOF的配置

appendonly yes则表示启用AOF

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

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

redis给我们提供了一个工具redis-check-aof --fix appendonly.aof

appendonly yes # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用

appendfilename "appendonly.aof"

 

# appendfsync always # 每次修改都会sync 消耗性能

appendfsync everysec # 每秒执行一次 sync 可能会丢失这一秒的数据# appendfsync no # 不执行 sync ,这时候操作系统自己同步数据，速度最快

 

 

优点

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

没秒同步一次，可能会丢失一秒的数据

从不同步，效率最高

 

缺点

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

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