Redis是内存数据库,如果不将内存中的数据库保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所以Redis提供了持久化功能。
面试和工作,持久化都是重点。
RDB(Redis DataBase)
什么是RDB?
在主从复制中,rdb就是备用的在从机上面,不占主机的内存,相对来说会比较方便一点。aof几乎不使用的。
在指定的时间间隔内将内存中的数据集体写入磁盘,也就是行话讲的Snapshot快照,它恢复的时候是将快照的文件直接读到内存里。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能会丢失。我们默认的就是RDB,一般情况下不需要修改这个配置。
有时候在生产环境我们会将这个文件进行备份。
RDB保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的!
我们测试一下:只要60s内修改了5次key,就会触发rdb操作,一旦触发rdb操作就会生成一个dump.rdb文件
save
保存配置文件
触发机制
- save的规则满足的情况下,会自动触发RDB规则
- 执行了 flushall 命令,也会触发我们的RDB规则
- 退出Redis,也会产生rdb文件
备份就自动生成一个dump.rdb文件
如何恢复RDB文件
- 只需要将rdb文件放到redis的启动目录下就可以了。Redis启动的时候会自动检查dump.rdb文件恢复里面的数据。
- 查看需要存在的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在dump.rdb文件,启动就会自动恢复其中的数据
几乎它本身的默认配置就够用了,但是我们还是需要去学习
优点:
- 适合大规模的数据恢复
- 如果对数据完整性不高
缺点:
- 需要一定的时间间隔进行操作,如果Redis意外宕机了,这个最后一个修改的数据就没有了
- fork进程的时候,会占用一定的内存空间
AOF(Append Only File)
将所有的命令都记录下来(history),恢复的时候就把这个文件全部在执行一遍
是什么
以日志的形式来记录每一个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加追加文件但不可以改写文件,Redis启动之初会读取该文件重新构建数据。也就是,Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF保存的是appendonly.aof
append only mode
默认是不开启的,需要手动进行配置。我们只需要将appendonly no
改为yes就开启了aof。
重启,Redis就可以生效了shutdown
,exit
。
如果这个appendonly.aof文件有错误,这个时候redis是启动不起来的,我们需要修复这个.aof文件。
Redis给我们提供了一个工具redis-check-aof --fix appendonly.aof
如果文件正常,重启就可以直接恢复了。会将错误的数据丢弃
重写规则
aof默认是文件的无限追加,文件会越来越大
如果aof文件大于64m,太大了。fork一个新的进程来将我们的文件进行重写。
优点和缺点
# appendfsync always # 每次修改都会 sync 消耗性能
appendfsync everysec # 每秒执行一次 sync,可能会丢失这1s的数据
# appendfsync no # 不执行 sync 这个时候操作系统自己同步,速度最快
优点:
- 每一次修改都同步,文件的完整性会更好
- 每秒同步一次,可能会丢失一秒的数据
- 从不同步,效率最高
缺点:
- 相对于数据文件来说,aof远远大于rdb,修复的速度也比rdb慢
- aof运行效率要比rdb慢,所以我们redis默认的配置就是rdb持久化
扩展:
如果Redis只做缓存,只希望你的数据在服务器运行的时候存在,就可以不使用任何持久化。
少年易老学难成,一寸光阴不可轻