redis持久化总结

RDB持久化大概运行原理：

假设我在redis.conf文件中配置 save 60 5 ,此时代表在一分钟内对redis中的key的修改次数达到5次就会执行一次rdb持久化。

这时候会fork一个子进程，用来负责从内存中读取数据然后保存到dump.rdb文件中，而主进程不参与任何的io操作，正常的处理客户端请求。这样子进程持久化完成后会用新的文件替换老的dump.rdb文件。

 

什么时候会触发dump.rdb文件?

1.满足配置文件中的配置save 60 5，就会触发持久化，生成rdb文件。

2.正常redis关机，会产生rdb文件。

3.执行flushall命令，会生成flushall文件。

 

如何恢复rdb文件？

通过config get dir命令获取rdb文件位置路径。

dump.rdb文件一般不做配置，会默认存放在 /usr/local/bin路径。

只需要将rdb文件放到启动目录下，redis启动会去检查dump.rdb文件，恢复其中的数据。

rdb的优点：

1.适合大规模的数据，dump.rdb

2.如果对数据完整性要求不高，也是可以用rdb。.

缺点：

1.如果redis意外宕机，那么可能会丢失数据。比如设置 save 60 5   一秒中修改5次key，会触发rdb持久化。假如在第59s宕机了，那么这一秒钟的数据就会丢失。

2.fork子进程的时候会占用一定的内存空间。

 

其实我一直在思考一个问题。面试的时候对面坐的人总是问redis宕机了怎么办？

其实我认为要是单机的话，可能也只会丢失一部分的数据，当然丢失数据是很严重的事，但是不要认为数据就没了。该怎么说就怎么说。不要直接卡住了。

 

AOF(appen only file)顾名思义，文件追加，就是将每次写的命令记录下来，以文件追加的形式。

appendonly yes #只需要将no改为yes,就开启aof了
 

我么可以看到开启aof，每次写的命令都会保存在appendonly.aof中

 

那么如果我对这个apof文件动点手脚，那么在redis重启开机后就会出现问题。

 

这时候可以用usr/local/bin下的 redis-check-aof  --fix appendonly.aof 命令对文件进行修复。

修复后就可以正常使用了

aof的优势：

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

每秒同步一次，可能只会丢失一秒钟的数据

从不同步，效率是最高的。

aof的缺点：

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

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

另外aof在文件体积越来越大的情况下，会有重写机制。可以配置。