目录
Redis 是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能!
1 RDB(Redis DataBase)方式
1.1 RDB 过程
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程 都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。 这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
我们默认的就是RDB,一般情况下不需要修改这个配置!
有时候在生产环境我们会将这个文件进行备份!
RDB保存的文件默认是dump.rdb 都是在我们的配置文件中的Snapshot快照模块中进行配置的!
1.2 触发机制
1.save的规则满足的情况下,会自动触发RDB规则,生成我们的RDB文件!
2.执行flushall命令,也会触发我们的RDB规则,生成我们的RDB文件!
3.退出redis,也会产生RDB文件!
备份就自动生成一个dump.rdb文件
1.3 如何恢复RDB文件
1.只需要将RDB文件放到redis的启动目录下就可以了,redis启动的时候会自动检查 dump.rdb文件,恢复其中的数据!
2.查看 dump.rdb文件存放的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在 dump.rdb 文件,那redis启动就会恢复其中的数据!
1.4 总结
优点:
1.适合大规模的数据恢复!
2.对数据的完整性要求不高! (你比如设置60s内修改1000次才生成rdb文件,但是59秒redis服务器就宕机了,这样数据就没了)
缺点:
1.需要一定的时间间隔进行操作!如果redis意外宕机了,这个最后一次修改的数据就没有了!
2.fork子进程的时候,会占用一定的内存空间!
2 AOF(Append Only File)方式
将我们的写入命令都记录下来,history,恢复的时候就把这个文件全部再执行一遍!
2.1 AOF过程
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来**(读操作不记录)**,只许追加文件 但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作!
2.2 修改配置文件
AOF保存的是appendonly.aof 文件
默认是不开启的,我们需要手动进行配置!我们只需要将appendonly 改为yes就开启了AOF!
重启redis就可以生效了
2.3 修复AOF文件
如果AOF文件有错误,这个时候redis是启动不起来的,我们需要修复这个AOF文件
redis给我们提供了一个命令工具,redis-check-aof --fix AOF文件 去修复我们的AOF文件
如果文件正常,重启就可以直接恢复了!
2.4 重写规则
AOF默认就是文件的无限追加,文件会越来越大!
如上图:如果某个时间点的AOF文件大于64M,太大了!它就会fork一个新的进程来将我们的文件进行重写!
这里的重写是指:例如:对一个String类型进行四次操作,我们只需读取最终的值,用最后一条命令来写入就减少了AOF文件大小
这样重写的好处是:将AOF文件变得更小,降低文件的占用空间,以便于更快的被redis加载!
2.5 总结
appendonly no # 默认不开启 , 使用RDB持久化
appendfilename "appendonly.aof" # 持久化文件的名字
# appendfsync always # 每次修改都会 sync ,消耗性能!
appendfsync everysec # 每秒执行一次 sync ,可能会丢失这1秒的数据!
# appendfsync no # 不执行 sync , 由操作系统自己同步数据,速度最快!
优点:
1.每一次修改都同步,文件完整性
2.每秒同步一次,可能会丢失一秒的数据
3.从不同步,效率最高
缺点:
1.相对于数据文件来说,AOF远远大于RDB,恢复的速度也比RDB慢!
2.AOF运行效率也要比RDB慢,所以说我们redis默认的配置就是rdb持久化!