Redis系列第5篇持久化
基本介绍
Redis持久化采用了RDB和AOF两种策略
RDB
在指定时间间隔内将内存中的数据集快照写入磁盘,即Snapshot快照,恢复是将快照文件直接读取到内存中
1.Redis会单独创建一个子进程(fork)来进行持久化
2.先将数据写入到一个临时文件中,待持久化过程完成后,再将这个临时文件覆盖到dump.rdb
整个过程中,主进程是不进行任何IO操作,确保了极高的性能。如果需要进行大规模的恢复,且对于数据恢复的完整性不敏感,那RDB方式比AOF更加高效
Fork
1.作用是复制一个与当前进程一样的进程,新进程中的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
2.在Linux程序中,fork()会产生一个和父进程完全相同的子进程,但子进程在此后会被exec系统调用,出于效率的考虑,Linux系统中引用了写时复制技术
3.一般情况父进程和子进程会共用一段物理内存,只有空间的各段的内容要发生变化的时候,才会将父进程的内容复制一份给子进程
RDB优点
RDB适合大规模的数据恢复,对于数据完整性和一致性要求不高更加适用,节省磁盘空间,恢复速度快
RDB缺点
Fork的时候,内存中的数据被拷贝了一份,大致两倍的膨胀性需要考虑。虽然Redis在fork时使用了写时拷贝技术,但如果数据庞大的时还是比较消耗性能。在备份周期在一定间隔时间做一次备份,如果Redis意外down掉,就会丢失最后一次快照后的所有修改
AOF
以日志的形式记录每个读写操作(增量保存),将Redis执行过程中所有记录都记录下来(读取操作不记录),只运行追加文件但不可改写文件,Redis启动之初会读取该文件重新构建数据,换言之,如果Redis重启就会根据日志文件的内容将写指令从前到后执行一次完整的数据恢复工作
执行流程
1.客户端请求写命令会被append追加到AOF缓冲区内
2.AOF缓冲区根据AOF持久化策略将操作sync同步到AOF文件中
3.AOF文件大小超过重写策略或者手动重写时,会对AOF文件Rewrite重写,压缩AOF文件容量
4.Redis服务重启时,会load加载AOF文件写操作达到数据恢复的目的
AOF和ROB同时打开的时候,系统默认读取AOF数据(数据不会丢失)
AOF优点
AOF的备份机制更稳健,丢失数据概率更低。可读的日志文本,通过操作AOF稳健,可以处理误操作
AOF缺点
比RDB占用更多的磁盘空间。恢复备份速度慢。每次读写都要同步的时候,有一定的性能压力。存在个别Bug造成不能恢复
官方推荐
官方推荐两种方式都使用,如果对数据不敏感,可以单独使用RDB。不建议单独使用AOF,可能会出现Bug。如果只是做内存缓存,两种方式可以都不使用