Redis-重写机制（减小AOF文件大小）

简介

本文介绍Redis的重写机制。

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。

AOF文件重写是把Redis进程内的数据转化为写命令并同步到新AOF文件的过程（新的AOF文件会比原来的小）。

AOF重写有两个作用：

1. 降低了文件占用空间
2. 更小的AOF文件可以更快地被Redis加载。

重写后AOF文件变小的原因

1. 进程内已经过期的数据不再写入文件。
2. 会删除旧的AOF文件中的无效命令
   1. 旧的AOF文件含有无效命令， 如：del key1、 hdel key2、 srem keys、 set a111、 set a222等。 重写使用进程内数据直接生成， 这样新的AOF文件只保留最终数据的写入命令。
3. 将多条写命令合并为一个
   1. 多条写命令可以合并为一个， 如： lpush list a、 lpush list b、 lpush list c可以转化为： lpush list a b c。
   2. 为了防止单条命令过大造成客户端缓冲区溢出， 对于list、 set、 hash、 zset等类型操作， 以64个元素为界拆分为多条。

重写的触发

AOF重写过程可以手动触发和自动触发：

1. 手动触发： 直接调用bgrewriteaof命令。（命令：redis-cli bgrewriteaof）
2. 自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
   1. auto-aof-rewrite-min-size： 表示运行AOF重写时文件最小体积， 默认为64MB。
   2. auto-aof-rewrite-percentage： 表示当前AOF文件空间（aof_current_size） 和上一次重写后AOF文件空间（aof_base_size） 的比值。
   3. 自动触发时机为：aof_current_size > auto-aof-rewrite-minsize && (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewritepercentage
      1. 其中aof_current_size和aof_base_size可以在info persistence统计信息中查看。（注意：只有开启了AOF才能看到这两个参数）

重写的流程

 1）执行AOF重写请求

如果当前进程正在执行AOF重写， 请求不执行并返回如下响应：

ERR Background append only file rewriting already in progress

如果当前进程正在执行bgsave操作， 重写命令延迟到bgsave完成之后再执行， 返回如下响应：

Background append only file rewriting scheduled

2）父进程执行fork创建子进程， 开销等同于bgsave过程

3.1）主进程fork操作完成后， 继续响应其他命令。

所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘， 保证原有AOF机制正确性。

3.2）由于fork操作运用写时复制技术， 子进程只能共享fork操作时的内存数据。

由于父进程依然响应命令， Redis使用“AOF重写缓冲区”保存这部分新数据， 防止新AOF文件生成期间丢失这部分数据。

4）子进程根据内存快照， 按照命令合并规则写入到新的AOF文件。

每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制， 默认为32MB， 防止单次刷盘数据过多造成硬盘阻塞。

5.1）新AOF文件写入完成后， 子进程发送信号给父进程

父进程收到信号后更新统计信息， 具体见info persistence下的aof_*相关统计。

5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。

5.3）使用新AOF文件替换老文件， 完成AOF重写。