【Redis】Redis持久化模式AOF

目录

引言

AOF持久化模式​编辑​编辑

AOF与RDB的混合持久化(4.x后的新特性)

AOF的优缺点

修复破损aof文件

到底用RDB还是AOF

引言

AOF就相当于上面的日志形式。是追加式备份。所有发生的写操作，新增啊，修改啊，删除啊，这些命令，都会记录在这个AOF日志里。
如果追求数据的一致性，RDB会丢失最后一次的备份数据，所以往往会采用AOF来做。AOF丢失的
数据会比RDB相对来说少一些。
需要注意，redis是先执行写操作指令，随后再把指令追加进aof中。有时候奇葩的面试官会问你先后顺序，有些同学会冷不丁的犹豫一会。
特点:

• 类似日志的形式，把所有写操作追加到文件，
• 追加的形式是append，一个个命令追加，而不是修改
  比如说，set k1 abc，set k2 def,set k1 123，虽然有两次k1，但是不会合并，而是追加。(后面会提到压缩)
• redis恢复的时候先恢复aof，如果aof有问题(比如破损)，则再恢复rdb.|
• redis恢复的时候是读取aof中的命令，从头到尾读一遍，然后数据恢复。
  可以通过 bgrewriteaof 手动触发。异步重写aof日志，假如重写失败，那么数据还是存在的，因为老的aof还在。
   

使用AOF引发的问题思考
Redis运行了好多年了，比如10年，用的AOF，那么假如某一天redis名机挂了
1.这个10年的AOF有 多大?最大可以占用多少空间?有没有可能达到10来个T，或者更大?

• 按理说会，如果你吃饱了没事做，就只对某个key，新增，修改，删除，无限次的做这样的作，持续了十来年，那么这个aof文件会很大，而且都是重复的命令。但是AOF可以压缩重写，使得体积不大。

2.恢复10几个T文件的时候，内存不大会不会溢出?

• 不会。虽然文件很大，但是有效的命令实际的不会很多。而且可以压缩重写，这样体积不大读取肯定更加快速。

3.10来个T的aof恢