【Redis】持久化机制

目录

• • [一、如何在 Redis 里持久化数据的？](#一、如何在 Redis 里持久化数据的？)
  • • [1. RDB（Redis DataBase）------ 内存的全量快照](#1. RDB（Redis DataBase）—— 内存的全量快照)
    • [2. AOF（Append Only File）------ 命令的流水账日志](#2. AOF（Append Only File）—— 命令的流水账日志)
    • [3. 两者混合使用](#3. 两者混合使用)
  • 二、如何确认开启持久化
  • • [1. 配置文件](#1. 配置文件)
    • [2. 状态验证与文件位置查看](#2. 状态验证与文件位置查看)
    • • [① 验证 AOF 是否成功开启](#① 验证 AOF 是否成功开启)
      • [② 验证混合持久化（Mixed Persistence）是否开启](#② 验证混合持久化（Mixed Persistence）是否开启)
      • [③ 查找持久化文件的最终保存路径](#③ 查找持久化文件的最终保存路径)
    • [3. 其它进阶修改](#3. 其它进阶修改)
    • • [① 灵活自定义 RDB 配置](#① 灵活自定义 RDB 配置)
      • [② 重启 Redis 服务令配置生效](#② 重启 Redis 服务令配置生效)

---

一、如何在 Redis 里持久化数据的？

MySQL 追求安全：数据必须写进硬盘。硬盘哪怕断电，磁介质或闪存颗粒上的数据也不会消失。但代价是慢。

Redis 追求速度：数据全部塞进内存。CPU 读写内存的速度比硬盘快了成百上千倍。但代价是"断电即失"。

为了兼顾"内存的速度"和"硬盘的安全"，Redis 引入了持久化机制。它的核心逻辑是：在内存中飞速读写，在后台悄悄把数据同步到硬盘。

当 Redis 触发持久化时，它会对整个内存数据进行操作。

只要持久化在运行，你写入的任何数据，都会被存入硬盘。

Redis 持久化的两种不同的方案：

1. RDB（Redis DataBase）------ 内存的全量快照

RDB 的本质就是定时全量备份。

它是怎么工作的？

Redis 会根据你设定的时间周期（或者使用默认周期），在后台开启一个子进程。这个子进程会把当前内存里的所有数据变成一个二进制的压缩文件（默认叫 dump.rdb）。

默认配置的致命盲区：

你刚装好 Redis 时，RDB 是默认开启的。它的规矩写在 /etc/redis.conf 配置文件里：

• save 900 1：15 分钟内至少 1 个 key 改变，就触发备份。
• save 300 10：5 分钟内至少 10 个 key 改变，就触发备份。
• save 60 10000：1 分钟内至少 10000 个 key 改变，就触发备份。

为什么要重新配置它？

默认规矩太宽松了！假设你的虚拟机在 4 分钟内只被修改了 5 个 Key，它不会触发任何备份。如果此时突然停电，这 4 分钟内写入的所有数据彻底蒸发。

深度优缺点分析：

优势： 文件体积小，恢复速度快得惊人。重启时，Redis 直接把 dump.rdb 读进内存就完事了。

劣势： 丢数据概率高。两次快照之间的时间段，就是无保护的"裸奔期"。

2. AOF（Append Only File）------ 命令的流水账日志

AOF 的本质就是增量命令审计。

它是怎么工作的？

它是个极其勤快的秘书。它不关心内存里最终剩下了什么，它只记录你做过什么动作。你每敲一个写命令（比如 SET、HSET、LPUSH），Redis 就会把这行命令转换成特定的文本格式，追加（Append）到硬盘的一个日志文件（默认叫 appendonly.aof）的末尾。

默认状态：

默认是关闭的（appendonly no）。在真实生产环境中，我们必须手动把它改成 appendonly yes。

核心配置（三大刷盘策略）：

开启 AOF 后，我们还要在配置文件里修改 appendfsync 参数，决定秘书多久把积攒的命令真正写进硬盘：

• always（极度安全）：每执行一条命令，立刻强制写硬盘。系统慢如蜗牛，硬盘寿命暴降。
• no（极度不安全）：执行完命令先放内存缓存里，什么时候写硬盘听 Linux 操作系统的。
• everysec（黄金行业标准）：每秒钟雷打不动写一次硬盘。哪怕断电，我们也只会丢失最近 1 秒钟内的数据。

深度优缺点分析：

超强优势： 极其安全，配合 everysec 策略，几乎做到了天衣无缝。

致命劣势：

1. 文件巨大。你把一个数字自增了 10 万次，AOF 会老老实实记 10 万行 INCR 账本。
2. 恢复极慢。重启时，Redis 必须把 AOF 日志里的所有命令从头到尾在内存里重演一遍。

3. 两者混合使用

RDB 快照 ：在指定时间间隔内（如 15 分钟至少 1 个 key 变化）将内存中的全部数据以二进制压缩文件（dump.rdb）保存到磁盘。恢复时直接加载文件，速度极快。缺点是如果两次快照之间发生宕机，未达到触发条件的新数据（哪怕已经改了多个 key 但时间间隔未到）就会永久丢失。

AOF 日志 ：记录每个写命令（如 SET、HSET）追加到日志文件（appendonly.aof），重启时逐条执行命令重建数据。可通过 appendfsync 配置数据安全性（如 everysec 最多丢一秒数据）。缺点是日志文件体积大、恢复速度慢（尤其写命令多时）。

两者弊端 ：RDB 可能丢较多数据，AOF 恢复慢且文件大。因此生产环境通常两者同时开启 ，并结合 Redis 4.0 引入的混合持久化来互补。

混合持久化是怎么做的？

从 Redis 4.0 开始，当同时开启 RDB 和 AOF 并启用 aof-use-rdb-preamble（默认 yes）时，AOF 重写（BGREWRITEAOF）产生的文件不是纯 AOF 格式，而是 RDB 快照 + 增量 AOF 命令：

1. 文件结构：AOF 文件开头是一份完整的 RDB 二进制快照（存储当前内存状态），快照之后是新写入的增量命令（以 AOF 文本格式追加）。
2. 写入过程：AOF 重写时，Redis 会先 fork 子进程生成内存快照写入 RDB 部分，然后继续将重写期间的新命令记录到缓冲区，最后将缓冲区内容追加到 AOF 文件末尾（作为 AOF 部分）。
3. 恢复过程 ：Redis 重启时，先读取 AOF 文件开头的 RDB 部分，瞬间恢复快照时的全部数据，然后再执行后续的 AOF 命令（这些命令很少，因此重放极快）。结果就是：既有 RDB 的快速恢复，又有 AOF 的高安全性（最多丢一秒数据）。

混合持久化的优势：AOF 文件比纯 AOF 小得多（RDB 部分压缩存储），恢复速度接近纯 RDB，数据安全性接近纯 AOF（最多丢一秒）。这也是目前生产环境最推荐的持久化方案。

二、如何确认开启持久化

在知道了 Redis 有这两种持久化的方式之后，就得知道怎么开启和配置它们了。

1. 配置文件

如果现在你在 Linux 中输入 ps -ef | grep redis 命令时，看到的是：redis-server *:6379，后面什么都没有，那就说明现在没有配置文件（如果输出类似 /user/bin/......redis.conf，那么这就是配置文件的路径，直接进去改参数就行）。

既然没有，就可以在网上下载或者自己手动配置。这里做手动配置的情况。

1. 创建正规的配置目录与数据目录

   sudo mkdir -p /etc/redis          # 存放配置文件
   sudo mkdir -p /var/lib/redis      # 存放持久化数据（dump.rdb 和 appendonly.aof）

2. 手动创建并编辑 redis.conf 文件

   sudo vi /etc/redis/redis.conf

   进入空白界面后，按下键盘上的 i 键进入编辑模式（看到左下角出现 -- INSERT --），然后把下面这段企业标准配置复制粘贴（或照着敲）进去：

   # ==================== 基础运行配置 ====================
   # 1. 允许 Redis 在后台默默运行，不霸占你的终端窗口
   daemonize yes
   
   # 2. 绑定 IP，允许所有网络连接（方便以后用外部工具连接）
   bind 0.0.0.0
   
   # 3. 关闭保护模式，配合上面的 bind 使用
   protected-mode no
   
   # 4. 给你的 Redis 设定访问密码
   requirepass 123456
   
   # ==================== 持久化核心配置 ====================
   # 5. 指定数据和持久化文件的存放目录（专属储物间）
   dir /var/lib/redis
   
   # 6. 开启安全的 AOF 持久化，并设定黄金刷盘策略（每秒记一次日记）
   appendonly yes
   appendfsync everysec
   
   # 7. 开启混合持久化大招（结合 RDB 的快与 AOF 的安全）
   aof-use-rdb-preamble yes

   检查无误后，按下 Esc 键，输入 :wq 回车，保存并退出。

3. 杀死正在裸奔的旧 Redis

   sudo pkill redis-server

4. 带着崭新的配置文件启动

   sudo redis-server /etc/redis/redis.conf

2. 状态验证与文件位置查看

修改完配置文件并重启后，我们如何验证持久化是否真正生效？这些文件又存放在哪里？请按以下步骤逐一排查。

① 验证 AOF 是否成功开启

连入 redis-cli 后，执行以下命令：

CONFIG GET appendonly

• 如何判断： 如果返回 "yes"，说明 AOF 持久化已成功开启。

② 验证混合持久化（Mixed Persistence）是否开启

在 redis-cli 中，输入以下命令查看混合持久化开关：

CONFIG GET aof-use-rdb-preamble

• 如何判断： 如果返回 "yes"，说明混合持久化大招已经就位。当后续触发 AOF 重写时，文件就会自动转换为"RDB 二进制开头 + AOF 文本结尾"的混合格式。

③ 查找持久化文件的最终保存路径

想要知道 AOF 和 RDB 文件在硬盘的哪个文件夹，可以分两步走：

1. 获取 Redis 数据基础根目录：
   在 redis-cli 中输入：

CONFIG GET dir

Redis 会返回一个绝对路径（例如："/var/lib/redis" 或 "/root"），这就是持久化数据的"大本营"。

2. 定位 AOF 专属子目录（Redis 7.0 及以上版本特性）：

在 Redis 7.0+ 版本中，官方引入了多文件 AOF 机制，AOF 文件不再直接堆在根目录下，而是存放在一个名为 appendonlydir 的子目录中。

你可以使用以下命令查看该目录的名字：

CONFIG GET appenddir

通常默认返回 "appendonlydir"。

💡 最终文件绝对路径总结：

• RDB 快照文件： 直接存放在根目录下，即 /var/lib/redis/dump.rdb。
• AOF 文件夹： 存放在根目录的子目录下，路径为 /var/lib/redis/appendonlydir/。进入该文件夹后，你会看到以 .manifest、.base.rdb、.incr.aof 结尾的一组文件。

3. 其它进阶修改

① 灵活自定义 RDB 配置

除了 AOF，你还可以根据业务的并发量，在配置文件中自定义 RDB 的快照频率。其格式为 save <秒数> <修改次数>：

• 自定义策略示例：

save 1200 100

这行配置意味着："在 1200 秒（20 分钟）内，如果至少有 100 个 Key 被修改，就自动触发一次 RDB 快照"。

• 彻底禁用 RDB 自动保存： 如果你只想用 AOF，不希望 Redis 自动拍 RDB 快照，可以在配置文件中加入：

save ""

• 手动强制触发 RDB 快照： 无需等待定时规则，你可以在 redis-cli 中随时手动输入以下命令，让 Redis 在后台立刻进行一次全量快照：

BGSAVE

② 重启 Redis 服务令配置生效

请务必记住，任何配置文件的修改，都必须重启 Redis 服务才能生效。在 CentOS 7 / Ubuntu 系统中，通常使用以下命令：

• 如果使用 systemd 管理服务（推荐）：

sudo systemctl restart redis
# 注：部分系统服务名叫 redis-server，命令为：sudo systemctl restart redis-server

• 如果是手动带路径启动的：

redis-cli -a <你的密码> shutdown
redis-server /etc/redis/redis.conf