一 什么是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是个紧凑压缩的二进制文件,代表redis在某个时间节点的数据快照.非常适合
- 缺点
- RDB方式数据没办法做到实时/秒级持久化(容易造成数据的丢失).因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁的执行成本比较高
三 AOF持久化
以独立日志的方式记录每次写命令,重启的时候在执行AOF文件中的命令达到恢复数据的目的,AOF的主要作用是解决持久化的实时性
3.1 AOF工作流程
AOF 的工作流程：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）
- 客户端发起写的请求,Redis会把写入请求命令追加到aof_buffer缓冲区中
- AOF缓冲区根据相应的策略向磁盘做同步操作
- 随着AOF文件越来越大,需要定期的对AOF文件进行重写,达到压缩的目的
- 当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 资源的进程。
