所有分类
  • 所有分类
  • 未分类

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重写。

4

评论0

请先

显示验证码
没有账号?注册  忘记密码?

社交账号快速登录