Lecture09-Redis-持久化

管理员
2026-10-17
Redis
59
0
文章目录

    [toc]

    单词词性音标含义
    persistencen./pəˈsɪstəns/持久化（把内存数据保存到磁盘，防止断电/重启丢失）
    forkv./n./fɔːk/分叉（fork() 复制进程，RDB 用子进程写快照不阻塞主线程）
    snapshotn./ˈsnæpʃɒt/快照（某一时刻完整数据的拷贝，RDB 文件即快照）
    rdbn./ˌɑː diː ˈbiː/Redis DataBase，默认的二进制快照持久化方式
    aofn./ˌeɪ əʊ ˈef/Append Only File，追加写命令的日志持久化方式
    appendv./əˈpend/追加（AOF 把写命令追加到文件末尾）
    fsyncv./n./ˈfsɪŋk/同步刷盘（把缓冲区的数据真正写入磁盘）
    manifestn./ˈmænɪfest/清单（Redis 7/8 多文件 AOF 的索引清单文件）
    rewritev./ˌriːˈraɪt/重写（压缩 AOF 体积，去掉冗余命令）

    Lecture09-Redis-持久化

    作为内存数据库，Redis 数据在内存，断电/重启即丢失，所以持久化是必须的。Redis 提供 RDB（快照） 与 AOF（日志） 两种机制。

    1、RDB（快照持久化）

    1、机制

    • 定期把内存中的全量数据序列化成二进制快照文件 dump.rdb。
    • 通过 fork() 子进程写文件，主线程不阻塞（写时复制）。
    • 恢复快：启动时直接加载二进制文件。

    rdb-flow


    2、触发时机

    触发方式说明
    save 配置规则触发满足时间间隔 + 修改次数条件自动触发
    shutdown 正常关闭关闭前执行一次保存
    手动 save同步保存（阻塞主线程，生产少用）
    手动 bgsave异步后台保存（fork 子进程）
    flushall（危险）也会生成（空的）快照文件
     
    # 手动后台保存
127.0.0.1:6379> bgsave
Background saving started

    3、相关配置

    # 触发条件：多少秒内至少多少次修改
save 3600 1 300 100 60 10000

# RDB 文件名
dbfilename dump.rdb

# 工作目录（RDB 保存位置）
dir /usr/local/redis

# 是否压缩
rdbcompression yes

# 是否做完整性校验
rdbchecksum yes

    想关闭 RDB：save ""。建议别全关，至少留一个兜底快照。


    4、优缺点

    优点缺点
    文件小、二进制、恢复快两次保存之间数据可能丢失
    对性能影响小（fork 子进程）fork 大内存时短暂阻塞/占内存
    适合全量备份、异地容灾无法做到实时持久化

    适用：缓存、允许少量丢失、追求快速恢复的场景。


    2、AOF（追加日志持久化）

    1、机制

    把每一条写命令追加到日志文件，重启时重放命令重建数据。读操作不记录。

    SET name tom   → 追加到 AOF
INCR number    → 追加到 AOF
重启时：按顺序重放所有命令 → 还原数据

    aof-flow


    2、相关配置

    # 开启 AOF
appendonly yes

# 刷盘策略
appendfsync everysec    # always / everysec / no
    appendfsync含义数据安全性能
    always每次写都 fsync 刷盘最高（几乎不丢）最低
    everysec每秒刷一次（默认）最多丢 1 秒中
    no交给操作系统决定最低最高

    生产常用 everysec：性能与安全平衡。


    3、Redis 8 的多文件 AOF（MP-AOF）

    Redis 7 开始，AOF 不再是一个文件，而是基础文件 + 增量文件 + 清单文件：

    appendonly.aof.1.base.rdb      # 基础文件（某时刻全量快照）
appendonly.aof.1.incr.aof      # 增量文件（基础文件之后的写命令）
appendonly.aof.2.incr.aof
appendonly.aof.manifest        # 清单（记录各文件及顺序，启动时按它加载）
    • 基础文件全量 + 增量文件记录变更 → 既快又全。
    • 恢复时：先加载基础文件，再按清单顺序应用增量文件。

    4、AOF 重写与修复

    ①重写（压缩体积）

    AOF 越来越大时，可把当前状态重写成一个更小的基础文件，丢弃冗余命令（如多次 SET 同一个 key 只留最后一条）。

    127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

    ②损坏文件修复

    AOF 文件被破坏会导致 Redis 启动失败，用工具修复（把错误位置之后截掉，保证能启动）：

    redis-check-aof --fix /usr/local/redis/appendonlydir/appendonly.aof.1.incr.aof

    修复不是"改对命令"，而是截断错误处之后的内容，保证能启动。建议先备份再修。


    5、优缺点

    优点缺点
    数据安全高（everysec 只丢 1 秒）文件比 RDB 大
    文本可读、可排查、可手动修复恢复慢（逐条重放）
    支持混合持久化（基础 RDB + 增量 AOF）always 时性能损耗明显

    3、RDB 与 AOF 选型

    方案数据安全恢复速度适用场景
    仅 RDB低（可能丢分钟级）快纯缓存、可丢数据
    AOF（everysec）中（丢 1 秒）较慢多数生产环境（推荐默认）
    AOF（always）高（几乎不丢）较慢金融、订单等关键数据
    RDB + AOF 混合高较快生产最佳实践（全量快照+增量日志）

    生产最佳实践：appendonly yes（everysec）+ 定期 RDB 全量备份。Redis 7/8 默认 aof-use-rdb-preamble 开启混合，基础文件即 RDB 格式，兼顾速度与安全。


    4、监控与验证

    # 查看持久化状态
127.0.0.1:6379> info persistence
# Persistence
loading:0
rdb_last_save_time:...
aof_enabled:1
aof_current_size:...

    5、课堂练习

    1. 查看当前 Redis 的 INFO persistence，确认 RDB/AOF 状态。
    2. 写入若干数据后执行 bgsave，在 dir 目录找到 dump.rdb，shutdown 后重启确认数据还在。
    3. 开启 appendonly yes 重启，观察 appendonlydir/ 下生成了 base/incr/manifest 文件。
    4. 用 redis-check-aof --fix 模拟修复一个被破坏的 AOF（先备份，第 2 节演示）。

    6、本节验证

    • 理解 RDB 快照机制、触发时机与相关配置 ✅
    • 理解 AOF 追加日志机制、刷盘策略与 Redis 8 多文件 AOF ✅
    • 理解 AOF 重写与损坏文件修复 ✅
    • 会根据场景选择 RDB/AOF 方案，并会验证持久化状态 ✅
    end