(四)Redis的持久化

一 什么是redis持久化

因为Redis数据是基于内存读写,为防止Redis服务器关闭或者宕机造成数据的丢失,我们通常需要对redis做持久化,即:把内存中的数据(命令)保存一份到磁盘中来做一份备份,当redis服务关闭或宕机后,在Redis服务器重启后将数据从磁盘加载到内存中,不至于造成数据的丢失。
Redis提供了两种持久化方式RDB和AOF,可以通过修改redis.conf来配置,开启Redis持久化后,在redis的安装目录会看到持久化文件:“appendonly.aof”和“dump.rdb”

Redis持久化原理

• 保存持久化数据

• 启动Redis载入持久化数据
  

二 RDB持久化

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

2.1 触发机制

手动触发:

• 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 # 是否采用校验和的方式，一般采用

2.2 RDB的优缺点

• 优点
  • RDB是个紧凑压缩的二进制文件,代表redis在某个时间节点的数据快照.非常适合备份,全量复制等场景
  • Redis加载RDB恢复数据远快于AOF方式
• 缺点
  • RDB方式数据没办法做到实时/秒级持久化(容易造成数据的丢失).因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁的执行成本比较高

三 AOF持久化

以独立日志的方式记录每次写命令,重启的时候在执行AOF文件中的命令达到恢复数据的目的,AOF的主要作用是解决持久化的实时性

3.1 AOF工作流程

AOF 的工作流程：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）

1. 客户端发起写的请求,Redis会把写入请求命令追加到aof_buffer缓冲区中
2. AOF缓冲区根据相应的策略向磁盘做同步操作
3. 随着AOF文件越来越大,需要定期的对AOF文件进行重写,达到压缩的目的
4. 当Redis服务器重启时,可以加载AOF文件进行数据恢复

3.2 AOF的三种同步策略

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

3.3 AOF的重写机制

随着命令不断的写入AOF,文件会越来越大,于是引入了AOF重写机制来压缩文件的体积,本质就是把一些过期的、没有用的、重复的、以及一些可以优化的命令进行一个简化，简化成一个较小的AOF文件。

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

3.4 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%

四 Redis 4.0混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

通过如下配置可以开启混合持久化(必须先开启aof)：

aof‐use‐rdb‐preamble yes

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的AOF 全量文件重放，因此重启效率大幅得到提升。

五 开发运维常见问题

fork 操作

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

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 资源的进程。