Redis 数据持久化
|
Redis
|
13

Redis 提供了两种主要的持久化方式，可以将内存中的数据保存到磁盘，防止服务器重启导致数据丢失。

1. RDB (Redis Database) 持久化

RDB 是一种快照存储持久化方式，具体就是将 Redis 某一时刻的内存数据保存到 硬盘的文件当中，默认保存的文件名为 dump.rdb，而在 Redis 服务器启动时， 会重新加载 dump.rdb 文件的数据到内存当中恢复数据。

1.1. 开启 RDB 持久化的 3 种方式

  • 客户端发送 save 命令：
    • 当客户端向服务器发送 save 命令请求进行持久化时，服务器会阻塞 save 命令之后的其他客户端的请求，直到数据同步完成。
    • 如果数据量大，同步数据会执行很久，而这期间 Redis 服务器也无法接 收其他请求，所以生产环境不推荐使用 save 命令。
  • 客户端发送 bgsave 命令：
    • 当客户端发服务发送 bgsave 命令时，Redis 服务器主进程会 forks 一个子进程来同步数据，将数据保存到 rdb 文件之后子进程会退出。所以，与 save 命令相比，使用 bgsave 命令同步数据时主进程仍然可以接收其他请求。
    • 但 forks 子进程是同步的，所以 forks 子进程时，一样不能接收其他请求。这意味着，如果 fork s一个子进程花费的时间太久(一般是很快的)，bgsave 命令仍然有阻塞其他客户的请求的情况发生。
  • 配置服务器自动触发：
    • 除了通过客户端发送命令外，还可以在 Redis 配置文件中指定到达触发RDB 持久化的条件。条件成立则自动进行数据持久化。
    • 示例：
save 900 1      # 900秒(15分钟)内有至少1个key被改变
save 300 10     # 300秒(5分钟)内有至少10个key被改变
save 60 10000   # 60秒内有至少10000个key被改变

dbfilename dump.rdb  # RDB文件名
dir ./               # 存储目录
rdbcompression yes   # 是否压缩RDB文件

# 注意：配置文件中的 save 并不是上面介绍的 save 命令，而是一个配置项，通过配置文件触发的 RDB 持久化都是异步的，会 forks 一个子进程来进行。
Bash

1.2. RDB 持久化流程

  • 生成临时 rdb 文件，并将内存数据写入。
  • 完成数据写入，删除原来的 rdb 文件。
  • 用临时文代替代正式 rdb 文件。

1.3. RDB 持久化的优缺点

  • 优点：
    • 与AOF方式相比，通过 rdb 文件恢复数据比较快。
    • rdb 文件可以启用压缩（rdbcompression yes），减少磁盘占用。
    • 由于 RDB 进行数据持久化使用子进程，所以对 Redis 服务器性能影响较小。
  • 缺点：
    • 可能丢失较多数据
      • RDB 是定时快照，如果 Redis 崩溃，最后一次快照后的数据会丢失（取决于 save 配置，如 save 900 1 表示 15 分钟至少 1 次变更才触发备份）。
      • 不适合对数据丢失零容忍的场景。
    • 大数据量时可能阻塞服务
      • 虽然子进程负责持久化，但如果数据量很大（如几十 GB），fork() 子进程可能短暂阻塞主进程（尤其在物理机上内存较大时）。
      • 在极端情况下，可能导致 Redis 短暂不可用。

2. AOF (Append-Only File) 持久化

与 RDB 存储某个时刻的快照不同，AOF 持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作日志追加（Append）方式写入以 .aof 为后缀的文件中。在 Redis 服务器重启时，会加载并运行 .aof 文件的命令，以达到恢复数据的目的。

2.1. 开启 AOF 持久化的方式

Redis 默认不开启 AO F持久化方式，我们可以在配置文件中开启并进行更加详细 的配置，如下所示：

# redis.conf

# 开启 aof 机制
appendonly yes
 
# aof 文件名
appendfilename "appendonly.aof"
 
# 写入策略
appendfsync always
# always：每条命令都同步，最安全但性能最低。
# everysec：默认写入策略，每秒写入一次 aof 文件，最多可能会丢失1s的数据。
# no：由操作系统来决定什么时候写入 aof 文件，数据容易丢失，不推荐使用。
 
# 保存目录,目录必须存在
dir /a/b/c/redis/
Bash

2.2. AOF 文件重写

AOF (Append Only File) 是 Redis 持久化机制之一，它通过记录所有写操作命令来保证数据安全。随着运行时间增长，AOF 文件会不断膨胀，因此 Redis 提供了 AOF 重写机制来优化文件大小。

AOF 重写的核心目的：

  • 体积压缩：消除冗余命令，将多个操作合并为最终状态
  • 性能优化：减少 AOF 文件体积，提高恢复速度

AOF 重写触发方式：

# 方式一：客户端命令触发
# 让服务器异步重写追加 aof 文件命令
bgrewriteaof

# 方式二：配置参数自动触发
# redis.cong 配置文件添加触发规则
auto-aof-rewrite-percentage 100  # 当前AOF文件比上次重写后体积增长100%时触发
auto-aof-rewrite-min-size 64mb   # AOF文件最小达到64MB才考虑重写
Bash

AOF 重写相关配置：

# 用于控制 AOF 重写期间的持久化行为，控制 AOF 重写时是否暂停主进程的 fsync 操作
no-appendfsync-on-rewrite no
# no（默认值）：AOF 重写期间，主进程继续正常执行 fsync（根据 appendfsync 配置）
# yes：AOF 重写期间，主进程暂停 fsync，牺牲部分数据安全性以换取更高的重写性能

# 子进程每生成 32MB AOF 数据就主动调用 fsync 同步到磁盘。
aof-rewrite-incremental-fsync yes
Bash

2.3. AOF 文件损坏修复

在写入 aof 日志文件时，如果 Redis 服务器宕机，则 aof 日志文件文件会出格式错 误。在重启 Redis 服务器时，Redis 服务器会拒绝载入这个 aof 文件。可以通过以 下步骤修复 aof 并恢复数据：

  • 先备份 aof 损坏的文件，防止修复时发生意外。
  • 使用 redis-check-aof 命令修复 aof 文件，示例如下：
# 修复 aof 日志文件
redis-check-aof -fix file.aof
Bash
  • 重启 Redis 服务器，加载已经修复的 aof 文件恢复数据。

2.4. AOF 持久化优缺点

优点：

  • 遇故障时丢的数据量少
  • AOF 只是追加日志文件，因此对服务器性能影响较小，备份的速度比 RDB 要 快消耗的内存较少。

缺点：

  • AOF 生成的日志文件太大，即使通过AOF重写日志文件体积仍然很大。
  • 恢复数据的速度比 RDB 慢。

3. 混合持久化 (RDB + AOF，Redis 4.0+)

在 Redis 4.0 及以上版本中，可以通过 混合持久化（RDB + AOF） 结合两者的优点，既能快速恢复数据（RDB 优势），又能保证较低的数据丢失风险（AOF 优势）。

混合持久化配置步骤：

  • redis.conf 配置文件
# 启用 AOF 持久化（必须开启，否则混合持久化不生效）
appendonly yes

# 启用混合持久化（Redis 4.0+ 支持）
aof-use-rdb-preamble yes

# AOF 文件名（默认：appendonly.aof）
appendfilename "appendonly.aof"

# AOF 同步策略（推荐 everysec，兼顾性能和数据安全）
appendfsync everysec

# AOF 重写时是否使用 RDB 快照（混合持久化依赖此配置）
aof-rewrite-incremental-fsync yes

# RDB 快照配置（可选，但建议保留）
save 900 1      # 15 分钟内至少 1 次修改则触发 RDB
save 300 10     # 5 分钟内至少 10 次修改
save 60 10000   # 1 分钟内至少 10000 次修改
dbfilename dump.rdb  # RDB 文件名
Bash
  • 重启 Redis 使配置生效

混合持久化文件结构：

启用后，AOF 文件（appendonly.aof）的内容会变成：

  • 前半部分：RDB 二进制格式（存储快照时的数据）。
  • 后半部分：AOF 文本格式（存储快照后的增量命令）。
    上一篇
    下一篇