Redis的持久化机制
为什么Redis需要持久化?(持久化的必要性)
Redis是一个内存数据库,如果没有持久化,那么在数据库连接时保存的数据,在数据库关闭连接时就会销毁。而我们希望在Redis中保存的数据能够持久化保存。
Redis提供了两种持久化的机制:RDB
和AOF
。
RDB
RDB:Redis DataBase
在指定的时间间隔内将内存中的数据集体快照
写入磁盘,也就是Snapshot快照,它恢复是将快照文件直接读到内存中。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上传持久化好的文件。整个过程中,主进程是不进行任何IO操作的
。这就确保了极高的性能。如果需要进行大规模数据的回复,且对于数据恢复的完整性不是非常敏感,那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
Redis默认使用的就是RDB的持久化策略,一般情况下不需要更改该配置
但是RDB持久化机制也是有缺点的:
假如说我们在持久化的时候宕机了,那么最后一次持久化的数据就没有在RDB文件中,可能会丢失文件。
RDB保存的文件就是dump.rdb文件
。
看一下配置文件
触发机制:
- save的规则满足的情况下,会自动触发rdb规则。
- 执行flushall命令,也会触发我们的rdb规则。
- 退出redis,也会产生rdb文件。
备份就自动生成一个dump.rdb。
如何恢复rdb文件:
只需要将rdb文件放在我们redis启动目录就可以,redis启动的时候回自动检查dump.rdb恢复其中的数据。
优点:
- 适合处理大规模的数据恢复。(而且在生成rdb文件时,主进程没有IO进程(是fork另一个子进程来执行的),因此效率很高)
- 对数据完整性要求不高的。(因为是要符合规定的规则,比如说60s内修改key10000次才产生dump文件,但是如果在59s时服务器宕机了,这时就丢失了文件)
缺点:
- 需要一定的时间间隔,如果redis意外宕机了,这个最后一次修改数据就没有了!
- fork子进程时,会占用一定的内存空间。
一般在生产环境下,我们会将dump文件备份,然后供后续使用
AOF
AOF
:(Append Only File)
将我们执行的所有命令都记录下来,相当于history,恢复的时候就将aof文件重新执行一遍。(只记录写的操作,不记录读的操作)。
aof默认是不开启的,需要手动修改配置文件的配置
。
如果aof文件在恢复数据库时,发现是aof文件时错误的,那么就要使用aof的检测文件来检测和修复然后再恢复redis。redis提供了一个工具redis-check-aof --fix
优点:
- 可以设置每一次修改都同步,那么文件的完整性会更好
- 默认开启的是每秒同步一次,那么假如服务器宕机的话,只会丢失1s的数据
- 也可以设置为从不同步,那么效率是最高的
缺点:
- 相对于数据文件来说,aof远远大于rdb,修复的速度也比rdb慢
- aof的运行效率也比rdb慢,所以rdb的默认配置是rdb开启,而aof关闭。