野生程序员 野生程序员

               流年,长短皆逝 浮生,往来皆客。  

目录
Redis持久化-AOF
/  

Redis持久化-AOF

AOF(Append Only File)

将我们的所有命令都记录下来,history,恢复的时候就把这个命令都执行一遍,Aof保存的是appendonly.aof

位置:APPEND ONLY MODE

image.png

默认是不开启的,我们需要手动进行配置!我们只需要applendonly,修改为yes就开启了aof!

如果aof文件有错误如何处理?

如果aof文件有错,这时候redis是不会启动成功的,我们需要修复aof文件

redis给我们提供了一个工具 redis-check-aof --fix

如果aof文件正常,那就可以正常启动了

优点和缺点!

优点:

  1. 每次修改都同步,文件的完整会更好
  2. 每秒同步一次,可能会丢失一秒的数据
  3. 从不同步,效率更高

缺点:

  1. 相对于数据文件来说 aof远远大于rdb,修复的速度也比rdb慢!
  2. aof运行效率也要比rdb慢,多以redis默认配置是rdb持久化!

拓展:

aof,rdb是两种 redis持久化的机制。用于crash后,redis的恢复。

rdb的特性如下:

Code:fork一个进程,遍历hash table,利用copy on write,把整个db dump保存下来。
save, shutdown, slave 命令会触发这个操作。
粒度比较大,如果save, shutdown, slave 之前crash了,则中间的操作没办法恢复。

aof有如下特性:

Code:把写操作指令,持续的写到一个类似日志文件里。(类似于从postgresql等数据库导出sql一样,只记录写操作)
粒度较小,crash之后,只有crash之前没有来得及做日志的操作没办法恢复。

两种区别就是,一个是持续的用日志记录写操作,crash后利用日志恢复;一个是平时写操作的时候不触发写,只有手动提交save命令,或者是关闭命令时,才触发备份操作。

选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(aof),还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行save的时候,再做备份(rdb)。rdb这个就更有些 eventually consistent的意思了。


标题:Redis持久化-AOF
作者:野生程序员
地址:http://www.yscxy.net/articles/2020/10/20/1603157610911.html