Redis持久化机制之AOF

因为RDB的持久化机制是定期全量备份，有可能导致最后一次的需要备份的数据还没来得及备份就丢失了，但其实也无所谓，毕竟是缓存如果追求数据的完整和安全性，就需要考虑AOF的机制了。

1. AOF特点

1. 以日志的形式来记录用户请求的写操作，读操作不会记录，因为写操作才会存储
2. 文件以追加的形式而不是修改的形式
3. redis的aof恢复其实就是把追加的文件从头到尾的读取执行写操作

2. AOF的优缺点

1. 优势

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

2. 劣势

   • 相同的数据，同一份数据，AOF比RDB大
   • 针对不同的同步机制，AOF会比RDB慢，因为AOF每秒都会备份做写操作，这样相对RDB来说就慢一些，如果设置为每一次写入都备份，那么redis的性能会下降
   • AOF发生过bug，就是数据恢复的时候数据不完整，显得AOF比较脆弱，为了防止bug的产生，AOF不会根据旧的指令去重构，而是根据当时缓存中存在的数据指令去重构，这样子就显得健壮和可靠了

3. AOF的配置

appendonly no # AOF默认关闭，yes可以开启
appendfilename "appendonly.aof" # AOF的文件名
# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是性能差
appendfsync everysec
no-appendfsync-on-rewrite no # 当重写AOF的时候是否要同步，no可以保证数据安全
# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

4. 采用RDB还是AOF?

1. 如果能接受一段时间的缓存丢失，那么可以使用RDB
2. 如果你要求数据完整性，那么就用AOF