文章目录

  • 一、RDB
  • 触发机制
  • RDB 优缺点
  • 二、AOF
  • 文件写入
  • AOF 的三种策略
  • 重写机制
  • AOF配置
  • 三、开发运维常见问题
  • fork 操作
  • 子进程开销和优化
  • AOF 追加阻塞


一、RDB

RDB 持久化是把当前进程数据生成快照保存到硬盘的过程，快照文件也就是一个 RDB 文件（二进制）。当我们需要对 redis 进行恢复，我们就可以去加载这个文件，将某时刻的备份文件恢复到 redis 中。

触发机制

  • save（同步）：阻塞当前 Redis 服务器，直到 RDB 过程完成为止，阻塞耗时较长，不建议线上环境使用。
  • bgsave（异步）：Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。
  • 自动生成：根据以下配置自动触发文件 dump，dump 操作就是 bgsave 。
save 900 1 # 当在900秒改变了1条数据，将触发 bgsave 操作
save 300 10 # 当在300秒改变了10条数据，将触发 bgsave 操作
save 60 10000 # 当在60秒改变了10000条数据，将触发 bgsave 操作
dbfilename dump-${port}.rdb # 一般的文件命名方式，加上端口区分
dir /bigdiskpath # 选择一个比较大的硬盘路径，甚至分盘
stop-writes-on-bgsave-error yes # 如果 bgsave 发生了错误，就停止写入
rdbcompression yes # 一般采用压缩格式
rdbchecksum yes # 是否采用校验和的方式，一般采用

RDB 优缺点

  • 优点
  • RDB 是一个紧凑压缩的二进制文件，代表 Redis 在某个时间点上的数据快照。非常适用于备份，全量复制等场景。
  • Redis 加载 RDB 恢复数据远远快于 AOF 的方式。
  • 缺点
  • RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。
  • 针对 RDB 不适合实时持久化的问题，Redis 提供了 AOF 持久化方式来解决。

二、AOF

以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 的主要作用是解决数据持久化的实时性，目前已经是 Redis 持久化的主流方式。

文件写入

  • AOF 的工作流程：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）
  • 所有的写入命令会追加到 aof_buf 缓冲区中
  • AOF 缓冲区根据对应的策略向硬盘做同步操作
  • 随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的
  • 当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复

AOF 的三种策略

  • always：首先 redis 写命令到 aof_buf 缓存区，然后缓冲区（always）会把每条命令 fsync 到磁盘 AOF 文件。
  • 优点：不丢失数据
  • 缺点：IO 开销大，一般的硬盘只有几百 TPS，无法满足 Redis 的高性能
  • everysec：首先 redis 写命令到 aof_buf 缓存区，然后缓冲区（每秒）会把命令 fsync 到磁盘 AOF 文件。
  • 优点：每秒一次 fsync 操作，适当保护磁盘
  • 缺点：最多可能丢失 2 秒数据（注意不是 1 秒，最后有分析）
  • no：首先 redis 写命令到 aof_buf 缓存区，什么时候该 fsync 是由操作系统决定的。
  • 优点：不用管
  • 缺点：不可控

重写机制

  • 随着命令不断写入 AOF，文件会越来越大，于是引入 AOF 重写机制压缩文件体积。其实就是把一些过期的、没有用的、重复的、以及一些可以优化的命令都可以进行一个化简（多条命令化简成一条命令，结果不变），化简成一个很小的 AOF 文件，这样有两个目的：
  • 降低了文件占用空间
  • 更小的 AOF 文件可以更快地被 Redis 加载
  • AOF 重写实现的两种方式
  • bgrewriteaof：客户端输入 bgwriteaof 命令，redis 会使用一个 linux 的 fork() 函数，生成一个子进程，子进程再进行 AOF 重写生成新的 AOF 文件。
  • AOF 重写配置自动触发
# 配置
auto-aof-rewrite-min-size # AOF文件重写需要的尺寸，也就是说当AOF多大的时候，才进行AOF的重写
auto-aof-rewrite-percentage # AOF文件增长率，比如这一次重写到了100M，下一次多久重写呢，假如说达到200M就重写，那么增长率就是100%
# 统计项
aof_current_size # AOF当前尺寸，aof_current_size > auto-aof-rewrite-min-size 触发重写
aof_base_size # AOF上次启动和重写的尺寸，增长率 = (aof_current_size - aof_base_size) / aof_base_size，增长率 > auto-aof-rewrite-percentage 触发重写
  • 重写流程
  • 1）执行 AOF 重写请求
  • 2）父进程执行 fork 创建子进程，开销等同于 bgsave 过程
  • 3.1）主进程 fork 操作完成后，继续响应其他命令
  • 3.2）由于 fork 操作运用写时复制技术，子进程只能共享 fork 操作时的内存数据。
  • 4）子进程根据内存快照，按照命令合并规则写入到新的 AOF 文件
  • 5.1）新 AOF 文件写入完成后，子进程发送型号给父进程，父进程更新统计信息
  • 5.2）父进程把 AOF 重写缓冲区的数据写入到新的 AOF 文件
  • 5.3）使用新 AOF 文件替换老文件，完成 AOF 重写

AOF配置

# AOF配置
appendonly yes # 要使用AOF所有功能就置为 yes，默认是 no
appendfilename "appendonly-${port}.aof" # AOF文件名称
appendfsync everysec # 每秒进行刷盘策略
dir /bigdiskpath # 保存目录
no-appendfsync-on-rewrite yes # 是否要做AOF的append操作，yes表示不做这个操作
# AOF重写配置
auto-aof-rewrite-min-size 64MB # AOF文件重写需要的尺寸，也就是说当AOF多大的时候，才进行AOF的重写
auto-aof-rewrite-percentage 100 # AOF文件增长率，比如这一次重写到了100M，下一次多久重写呢，假如说达到200M就重写，那么增长率就是100%

三、开发运维常见问题

fork 操作

  • 同步操作，对于大多数操作系统来说 fork 是个重量级操作
  • 改善 fork 操作的耗时：
  • 优先使用物理机或者高效支持 fork 操作的虚拟化技术
  • 控制 Redis 实例最大可用内存 maxmemory，fork 耗时跟内存量成正比，线上建议每个 Redis 实例内存控制在 10GB 以内
  • 合理配置 Linux 内存分配策略，避免物理内存不足导致 fork 失败
  • 降低 fork 频率，例如放宽 AOF 重写自动触发机制，避免不必要的全量复制

子进程开销和优化

  • CPU优化
  • 内存优化
  • 硬盘优化

AOF 追加阻塞

当开启 AOF 持久化时，常用的同步硬盘的策略是 everysec，用于平衡性能和数据安全性。对于这种方式，Redis 使用另一条线程每秒执行 fsync 同步硬盘。当系统硬盘资源繁忙时，会造成 Redis 主线程阻塞。

  • 阻塞流程分析
  • 1）主线程负责写入 AOF 缓冲区
  • 2）AOF 线程负责每秒执行一次同步磁盘操作
  • 3）主线程负责对比上次 AOF 同步时间：
  • 如果距上次同步成功时间在 2 秒内，主线程直接返回
  • 如果距上次同步成功时间超过 2 秒，主线程将会阻塞，直到同步完成
  • 可以发现两个问题：
  • 1）everysec 配置最多可能丢失 2 秒数据，不是 1 秒。
  • 2）如果系统 fsync 缓慢，将会导致 Redis 主线程阻塞影响效率。
  • AOF 阻塞问题定位：
  • 发生阻塞时，将会输出 Redis 日志，用于记录 AOF fsync 阻塞导致拖慢 Redis 服务的行为
  • 每当发生 AOF 追加阻塞事件时，在 info Persistence 统计中，aof_delayed_fsync 指标会累加，查看这个指标方便定位 AOF 阻塞问题。
  • AOF 同步最多允许 2 秒的延迟，当延迟发生时说明硬盘存在高负载问题，可以通过监控工具如 iotop，定位消耗硬盘 IO 资源的进程。