Redis持久化

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