目录

引言

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恢复需要多久，有没有可能1天?1周？

• 按照现有情况来说，有可能吧。

以上三点都是aof文件庞大而出现的顾虑，其实aof可以重写，对日志有一个重写机制 bgrewriteaof其实也就是瘦身的作用，尝试想一想，如果一个人很胖了，不能越来越胖吧，应该时不时的运动下瘦个身，那么aof重写也是一个道理。

AOF持久化模式

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

yes:AOF重写，redis会把当前所有的数据以rdb形式存入到aof中，这都是二进制数据，数据量小，随后新的数据以aof形式追加到这个aof中，那么这个aof中包含两种文件类型数据，一个是rdb，一个是aof，那么恢复的时候redis会同时恢复，这样恢复过程会更快。这相当于是一个混合体。
no:关闭混合模式，aof只会压缩重复的命令，这是4.x以前老版本的机制，也就是把重复的没有意义的指令去除，减少文件体积，也减少恢复的时间。

可能会有同学会问，在重写AOF的时候，如果有新的命令进来要写入怎么办?那么他其实也会fork一个子进程，子进程复制重写，而新的那些写入命令会被记录到一个缓冲区，待子进程重写完毕后，缓冲工区的新的写命令会被追加到新的AOF文件中，这样就保持了数据在重写前后的一致性

AOF的优缺点

优点

• 耐用性高，秒级别备份：AOF更加耐用，可以以秒级别为单位备份(通常我们都是每设置为1秒)，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性。所以AOF可以每秒备份一次，使用fsync操作。
• log日志追加，不惧怕磁盘大小限制：以log日志形式追加，如果磁盘满了，会执行redis-check-aof 工具
• aof过大重写：当数据太大的时候，redis可以在后台自动重写aof，当redis继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端的读写操作。
• 日志形式更加有利于redis解析和恢复：AOF 日志包含的所有写操作，会更加便于redis的解析恢复

缺点 

• 相同数据量，AOF比RDB大，更耗时：相同的数据，同一份数据，AOF比RDB大，而且恢复起来也会很耗时，很慢
• 同步比RDB慢：针对不同的同步机制，AOF会比RDB慢，因为AOF每秒都会备份做写操作，这样相对与RDB来说就略低。 每秒备份fsync没毛病，但是如果客户端的每次写入就做一次备份fsync的话那么redis的性能就会下降。
• AOF数据可能不完整：AOF发生过bug，就是数据恢复的时候数据不完整，这样显得AOF会比较脆弱，容易出现bug，因为AOF没有RDB那么简单，但是呢为了防止bug的产生，AOF就不会根据旧的指令去重构，而是根据当时缓存中存在的数据指令去做重构，这样就更加健壮和可靠了。

修复破损aof文件

如果aof文件破损，那么可以修复一些无用的命令，使得其还是可以继续恢复正常内容:
redis-check-aof --fix [aof文件名]目的:删除不符合语法的指令
aof-load-truncated yes:Redis启动加载aof，命令语法不完整则修复。设置为no，Redis启动失败，需要手动用redis-check-aof 工具修复

到底用RDB还是AOF

般来说，可以RDB+AOF的同时开启使用。上面已经说了，可以把它们作为一个混合体去使用。如果说用户对redis的写操作不多甚至没有，95%以上都是读操作，那么用rdb也没啥问题，我们有一个项目是采用的缓存预热方式，用户几乎没有写操作，所以直接采用RDB就够用了，因为哪怕redis挂了，甚至RDB没了，数据还是能通过预热重新载入。如果说你们的Redis要作为一部分的数据库来使用，那么需要用到aof，或者rdb&aof的混合模式这样数据的完整性就更大了