Redis持久化:
Redis是内存数据库,如果不将内存中的数据保存在磁盘,那么一旦服务器进程退出,服务器中数据也会消失,所以Redis提供了持久化功能!
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里,
Redis会单独创建(fork)一个子进程进行持久化,会先将数据写入到一个临时文件中,待持久化过程结束了,再用这个临时文件替换上次持久化好的文件. 整个过程中,主进程是不进行任何的io操作的. 这就确保了极高的性能.如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效．RDB的缺点是最后一次持久化后的数据可能丢失.我们默认的就是RDB，一般情况下不需要修改这个配置！
RDB保存的文件是dump.rdb(会在生产环境备份这个文件)
触发机制:
1.save规则满足的条件,会自动触发rdb规则
2.执行flushall的时候,会自动产生rdb文件
3.退出的时候,也会产生rdb文件
恢复rdb文件:
1.只需将rdb文件放在redis的启动目录,redis启动的时候就会自动检查rdb文件,恢复其中的数据
2.查看rdb文件存放的目录
优点:
1.适合大规模数据恢复;
2.对数据完整性不敏感
缺点
1.需要一定的时间间隔进程操作,如何服务器意外宕机,那么最后一次修改的数据就丢失了;
2.fork进程的时候,会占用一定的内存空间;
AOF(Append only file)
将我们的命令全部记录下来,history,恢复的时候全部执行一遍这个文件中的命令
流程如下:
以日志的形式来记录每个写操作,将redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复
AOF保存的是 appendonly.aof 文件
配置文件:
默认是不开启的,需要我们手动配置,将appendonly改为yes就启动了aof!
重启redis就可以生效了;
如果这个aof文件有错位,redis是连接不上的,需要使用redis-check-aof --fix 修复这个文件
如果aof文件大于64mb,就会fork一个新进程来重写文件
