Redis持久化机制之AOF

谁践踏了优雅 2023-02-18 06:27 62阅读 0赞

因为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