什么是 AOF 持久化策略?
AOF 即 append only file，当 redis 采用这这种数据持久化策略的时候，每当 redis 服务器收到一条更新命令时，操作结束之后会将这条命令添加到 aof 内存缓冲区，特定的时间下刷新缓冲区到磁盘文件中，也就是我们的 aof 文件。
默认的 redis 启动配置文件中，会有这么两条配置：
- appendonly 指定 redis 是否启用 AOF 持久化策略
- appendfilename 指明生成的 AOF 文件名称
redis.conf 中还有 appendfsync 这么一条配置，它指明 AOF 文件的写入频率，即便 linux 中文件 IO 使用的高效的 epoll，但每收到一条更新命令就进行一次文件 IO，未免也太低效，况且也没必要。
appendfsync 的配置项有以下三种值可选：
- always：每一次系统 serverCorn 函数调用就刷新一次缓存区
- everysec：每秒执行一次磁盘写入，期间所有的命令都会存储在 aof 缓存区
- no：不做控制，任由操作系统决定什么时候刷新缓冲区
redis 默认配置是 everysec，即每秒刷新一次缓存区。
AOF 重写
所以，理论上来说，随着 redis 服务器运行时间的持续，生成的 aof 文件只会越来越大，redis 提供 AOF 重写策略帮助优化和压缩 aof 文件。
比如：
set a "a"
set b "b"
set c "c"
del a
del b
正常情况下，aof 文件中会保存着五条命令的 log，然后数据恢复的时候依次执行即可。而当你启动 AOF 重写后，实际上我们的 aof 文件中只有 set c “c” 这一条命令的 log。
以上只是一个简单的示例，实际上 AOF 重写达到的效率比这优秀的多的多，往往能将几百条甚至几千条的命令日志，重写优化成个位数。带给我们最直观的好处就是，aof 文件体积变小，数据恢复速度变快。
一般来说，我们可以通过向 redis 服务器发送 bgrewriteaof 命令触发服务器对 aof 文件进行重写，如果当前有正在运行的重写子进程，则本次重写会推迟执行，否则，直接触发一次重写。
除此之外，我们还可以在配置文件中配置 aof 文件达到多大, 自动触发文件重写。
因为 aof 文件重写一样是 fork 子进程并由子进程处理的，主进程依然提供服务，所以 redis 还提供一块重写缓冲区，当发现有子进程正在进行 aof 文件重写，最新的请求命令除了会添加到 AOF 缓冲区，还会添加进 AOF 重写缓冲区，当子进程完成重写任务后，主进程阻塞式将重写缓冲区的命令日志添加进最新的 aof 文件中。
配置
no-appendfsync-on-rewrite是否在重写AOF时, 关闭掉正常的AOFappend, 配置了当 redis 服务器因为某些情况即将阻塞（例如 save）时是否需要将缓冲区中的 aof 命令写入到磁盘，配置 yes 则每次遇到阻塞操作时刷新缓存到磁盘，配置为 no 则无需关心服务器阻不阻塞，缓存命令在缓存区。auto-aof-rewrite-percentage配置了当 aof 文件相较于上一版本的 aof 文件大小的百分比达到多少时触发 AOF 重写。举个例子，auto-aof-rewrite-percentage 选项配置为 100，上一版本的 aof 文件大小为 100M，那么当我们的 aof 文件达到 200M 的时候，触发 AOF 重写。auto-aof-rewite-min-size配置了最小能容忍 aof 文件大小，超过这个大小必须进行 AOF 重写。- 注意2, 3 条需要同时满足才能触发
