目录
之前给大家介绍了RDB的持久化方式,今天给大家来介绍redis中的另一种持久化方式----AOF
一、AOF(Append Only FIle)
以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis 启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF 持久化记录服务器接收到的每个写操作,在服务器启动时再次播放,重建原始数据集。命令使用与 Redis 协议本身相同的格式以AOF记录。当日志变得太大时,Redis 能够在后台重写日志。
二、持久化流程
AOF是默认关闭的,当AOF开启后,每当redis检测到有修改或增加数据的操作时,就会将命令追加到AOF文件中。
AOF在持久化时依旧是先fork出一个子进程,子进程开始在一个临时文件中写入新的基础 AOF,主进程打开一个新的增量 AOF 文件以继续写入更新,当子进程完成基础文件的重写后,父进程会收到一个信号,并使用新打开的增量文件和子进程生成的基础文件来构建临时清单,并将其持久化。
三、日志重写
随着写入操作的执行,AOF 变得越来越大。例如,如果您将计数器递增 100 次,您最终会在数据集中得到一个包含最终值的键,但在 AOF 中有 100 个条目。重建当前状态不需要其中的 99 个条目。重写就是将这100次的修改,合并为一条命令。
日志重写使用与快照相同的写时复制技巧并且重写是完全安全的。在 Redis 继续附加到旧文件的同时,使用创建当前数据集所需的最少操作集生成一个全新的文件,一旦第二个文件准备好,Redis 就会切换这两个文件并开始附加到新文件。
四、AOF的优点和缺点
优点:
- 使用 AOF 数据的完整性会更好
- 可以有不同的 fsync 策略:根本不 fsync、每秒 fsync、每次查询时 fsync。使用每秒 fsync 的默认策略,写入性能仍然很棒。fsync 是使用后台线程执行的,当没有 fsync 正在进行时,主线程将努力执行写入,因此只能丢失一秒钟的写入。
缺点:
- AOF 文件通常比相同数据集的等效 RDB 文件大
- AOF 运行效率略低于RDB
好了,这次的文章就到这里,喜欢的同学可以点赞收藏,遇到问题,可以评论,或者留言,我一定会第一时间给到回馈,感谢观看!!
注:本文为本人学习时心得分享,有讲错或者需要改正的地方,请指正,我会虚心接受