一简介:
AOF是redis持久化策略的选择之一,让我们来一探究竟
二 核心设计思路
AOF 以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。
三 写入 和保存概念阐述
WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。
SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。
四 保存的触发条件
1 AOF_FSYNC_NO ：
概念：只写入 不保存
风险: 损失上一次rsync后的命令 写入-阻塞 保存-阻塞
触发: 1 AOF 或 Redis 关闭时执行，2 由操作系统触发刷新文件到磁盘
2 AOF_FSYNC_EVERYSEC ：
概念:每一秒钟保存一次。
风险: 损失前一秒的命令 写入-阻塞 保存-不阻塞
触发:每秒触发写入和保存
3 AOF_FSYNC_ALWAYS ：
概念:每执行一个命令保存一次 高消耗,最安全,
风险:损失上一个命令 写入-阻塞 保存-阻塞
触发: 每条命令确保保存到磁盘后才会处理下个请求
五 重写功能
1 所谓的“重写”其实是一个有歧义的词语， 实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值 直接读取 list 键在数据库的当前值,所以
aof的重写是一个检索现有数据重写生成AOF文件的操作,是一个高消耗的cpu操作,需要在低峰期进行、
2 rewrite本身也是被fork出的一个子进程,还会有个aof重写缓存,针对重写期间的变更.最后再重新应用
3 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件.完成重写 有最后的写入缓存和改名操作会造成主进程阻塞
4 AOF 重写: 被修改的内存页 + AOF 重写缓冲区 基本算是内存消耗
六 重写的触发条件
手动触发 BGREWRITEAOF
自动触发
- 没有 BGREWRITEAOF/BGSAVE 在进行。
- 当前 AOF 文件大小大于 server.aof_rewrite_min_size （默认值为 1 MB）。
- 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。
七 参数
appendonly 开启
appendfilename 文件名
appendfsync 写入策略
auto-aof-rewrite-percentage 当前和上次的AOF文件增长大小对比.进行重写
auto-aof-rewrite-min-size 重写最小值
八 须知
redis一定会优先基于aof去恢复,如果想实现rdb恢复,需要预先关闭aof功能,再启动redis