(四)Redis的持久化

关注

原创最新推荐文章于 2026-09-17 10:00:00 发布 570 阅读 AI 写同款· GEO 优化 ›

[Unity_Plastic SCM小技巧] 使用 UnityYAMLMerge 工具合并场景和预制件文件首先YAMLMerge工具其实并不局限于PlasticSCM，git也可以，它是内置在Editor内的一个更加智能的版本控制工具，只不过正常不会启用，他的目录在C:\Program Files\Unity\Editor\Data\Tools\UnityYAMLMerge.exe(Unity Editor安装目录)，MAC上：/Applications/Unity/Unity.app/Content... 阅读详情

一什么是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）
在这里插入图片描述

客户端发起写的请求,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 资源的进程。