IT策士 10余年一线大厂经验专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章助你少走弯路。Redis 以极致的性能著称核心原因之一就是所有数据都在内存中读写。但内存的特性是易失的——一旦断电或进程崩溃所有数据瞬间消失。如果 Redis 只做缓存还好数据丢了可以从数据库重新加载可当它承载着分布式锁、计数器、消息队列等关键业务数据时丢数据就是事故。因此Redis 提供了两种持久化机制将内存数据保存到磁盘RDB快照和AOF追加日志以及它们的结合体——混合持久化。本文带你彻底理解这三种方案的工作原理、配置方法、优缺点和实战策略让你面对“会不会丢数据”这类问题时从容作答。1. 为什么需要持久化先理清一个概念持久化不是“备份”而是数据从内存到磁盘的同步过程。它的价值体现在故障恢复进程崩溃或服务器重启后能恢复数据减少损失。数据迁移将 RDB/AOF 文件复制到另一台机器快速恢复整个数据集。冷备归档定期保存某一时刻的完整数据快照。当然持久化不是免费的——它消耗磁盘 I/O、CPU 和内存需要在性能和数据安全之间做权衡。理解每种方案的原理才能做出正确选择。2. RDBRedis Database—— 内存快照2.1 什么是 RDBRDB 就是在某个时间点把 Redis 中所有数据生成一份压缩的二进制快照文件默认名为dump.rdb保存到磁盘。可以把它理解为给 Redis 内存拍了一张“照片”这张照片就是当时全部数据的完整拷贝。2.2 RDB 的触发方式① 手动触发# 阻塞主进程直到保存完成生产环境禁用127.0.0.1:6379SAVE OK# 后台异步保存推荐127.0.0.1:6379BGSAVE Background saving startedSAVE在主进程中执行保存期间 Redis不能处理任何命令。数据量大时会严重阻塞绝对不要在生产环境使用。BGSAVEfork 一个子进程由子进程负责写入 RDB 文件主进程继续处理请求。这就是我们日常使用的命令。② 自动触发配置文件中设置打开redis.conf你会看到类似这样的配置# 格式save seconds changes# 含义在 N 秒内如果至少有 M 个键被修改就触发一次 BGSAVEsave9001# 900 秒15分钟内至少 1 个键被修改save30010# 300 秒5分钟内至少 10 个键被修改save6010000# 60 秒内至少 10000 个键被修改多条规则是或关系满足任意一条就触发。也可以清空save配置来禁用自动 RDB但BGSAVE手动触发仍有效。③ 其他自动触发场景主从复制时主节点自动执行BGSAVE生成 RDB 文件发给从节点。执行SHUTDOWN关闭 Redis 时如果没有开启 AOF会自动执行一次SAVE。执行FLUSHALL后如果配置了自动保存规则会触发一次 RDB生成空快照非常危险。2.3 RDB 工作原理BGSAVE 流程主进程 子进程 │ │ ├── fork()──────────────────│(写时复制共享内存页)│ │ ├── 继续处理客户端命令 ├── 遍历所有数据 │ ├── 写入临时 RDB 文件 │ ├── 完成后原子重命名为 dump.rdb │ └── 退出 │ │ └── 子进程结束主进程继续服务关键点fork()使用了操作系统的**写时复制Copy-On-Write**机制。fork 出的子进程和父进程共享同一块物理内存只有当父进程修改数据时操作系统才会把对应的内存页复制一份。这样既保证了子进程能看到 fork 瞬间的完整数据又不会过度占用内存。⚠️ 如果 fork 后父进程写入量很大会导致大量内存页被复制内存占用可能短时间内翻倍。这也是为什么 Redis 需要预留一半内存的原因之一。2.4 RDB 配置详解# redis.conf# RDB 文件名dbfilename dump.rdb# RDB 文件保存路径需确保 Redis 有写权限dir/data/redis# 保存规则前面已介绍save9001save30010save6010000# 写入错误时是否停止接受写入建议 yesstop-writes-on-bgsave-erroryes# 是否压缩 RDB 文件CPU 换磁盘空间rdbcompressionyes# 是否对 RDB 文件做完整性校验rdbchecksumyesPython 中查看持久化配置importredis rredis.Redis(decode_responsesTrue)# 查看 RDB 相关配置forkeyin[dbfilename,dir,rdbcompression,rdbchecksum]: print(f{key}: {r.config_get(key)[key]})# 手动触发 BGSAVEresultr.bgsave()print(fBGSAVE 是否触发: {result})# 查看最近一次 BGSAVE 是否成功返回 Unix 时间戳last_saver.lastsave()print(f上次成功保存时间: {last_save})输出示例dbfilename: dump.rdb dir: /data rdbcompression:yesrdbchecksum:yesBGSAVE 是否触发: True 上次成功保存时间:17180928002.5 RDB 的优缺点✅优点文件紧凑单一压缩二进制文件非常适合冷备和灾难恢复。恢复速度快直接加载二进制数据到内存比逐条回放 AOF 快得多。性能影响小BGSAVE由子进程完成主进程只负责 fork不影响正常请求处理。适合主从同步主从复制首次全量同步直接传 RDB 文件。❌缺点会丢数据两次 RDB 之间的数据没来得及持久化一旦宕机就丢失。大数据量时 fork 代价高内存越大fork 越慢毫秒到秒级可能阻塞主进程。写时复制导致内存压力频繁写入时内存占用可能暴涨。3. AOFAppend Only File—— 命令日志3.1 什么是 AOFAOF 记录的是每一条修改数据的 Redis 命令写入、删除、修改按时间顺序追加到日志文件中。重启时Redis 通过逐条回放 AOF 中的命令来重建数据。可以把它理解为不是给数据拍照而是记录下了“拍照后发生的每一条改动”。3.2 AOF 的开启与基本配置# redis.confappendonlyyes# 开启 AOFappendfilenameappendonly.aof# AOF 文件名dir/data/redis# 存放目录与 RDB 共用重启 Redis 后用redis-cli观察127.0.0.1:6379SET nameIT策士OK127.0.0.1:6379SET age30OK127.0.0.1:6379INCR counter(integer)1查看 AOF 文件内容通过 Docker 进入容器或直接在服务器上$cat/data/appendonly.aof *3$3SET$4name$8IT策士 *3$3SET$3age$230*2$4INCR$7counterAOF 文件是 Redis 协议格式的纯文本可读可解析。如果误操作FLUSHALL还可以手动编辑 AOF 文件删除那条命令然后恢复数据仅限紧急情况。3.3 AOF 写入策略appendfsyncRedis 提供三种写入磁盘的策略由appendfsync配置# 每次写命令都同步到磁盘最安全但最慢appendfsync always# 每秒同步一次默认性能与安全的最佳平衡appendfsync everysec# 完全依赖操作系统缓冲区刷新最快但可能丢大量数据appendfsync no为什么everysec是最佳平衡Redis 主线程负责将 AOF 写入内存缓冲区然后由单独的 AOF 刷盘线程每秒执行一次fsync系统调用将缓冲区数据真正写入磁盘。主线程不参与实际的磁盘写入所以对性能影响极小。1 秒的数据丢失窗口对于绝大多数互联网场景是可接受的。3.4 AOF 重写Rewrite—— 防止文件无限膨胀AOF 会不断追加命令文件大小必然持续增长。假设一个计数器INCR了 100 次AOF 里会有 100 条INCR命令而实际上恢复数据只需要最后的值。AOF 重写就是 Redis 自己创建一个新的 AOF 文件只包含重建当前数据集所需的最少命令。# 手动触发重写127.0.0.1:6379BGREWRITEAOF Background append onlyfilerewriting started自动重写配置# 当 AOF 文件体积比上次重写后增长了 100%且超过 64MB 时自动触发重写auto-aof-rewrite-percentage100auto-aof-rewrite-min-size 64mb重写流程主进程 子进程 │ │ ├── fork()──────────────────────│ │ ├── 读取数据库数据 │ ├── 生成新 AOF 文件最小命令集 │ └── 退出 ├── 期间的新命令同时写入 │ ├── 旧 AOF 缓冲区正常 AOF │ └── AOF 重写缓冲区记录增量 │ └── 子进程完成后将重写缓冲区的增量写入新 AOF然后原子替换旧 AOF这个过程与 RDB 的BGSAVE非常类似利用子进程和写时复制主进程几乎不受影响。3.5 AOF 相关配置总览# 开启 AOFappendonlyyes# 文件路径appendfilenameappendonly.aof# 写入策略appendfsync everysec# 重写期间是否继续同步旧 AOFyes 保证安全但可能阻塞no-appendfsync-on-rewrite no# 自动重写触发条件auto-aof-rewrite-percentage100auto-aof-rewrite-min-size 64mb# AOF 文件尾部损坏时是否允许启动yes 会忽略尾部错误尝试恢复aof-load-truncatedyes3.6 AOF 的优缺点✅优点数据更安全everysec最多丢 1 秒数据always完全不丢。可读性好AOF 文件是 Redis 协议文本可直接查看和编辑。自动重写防止文件无限增长保持文件体积可控。❌缺点恢复速度慢重新回放所有命令大数据量时远比 RDB 慢。文件体积大相同数据集AOF 文件通常比 RDB 大。写入性能有损耗即使everysec每秒刷盘也会消耗 I/O。4. 混合持久化 —— Redis 4.0 的最佳方案既然 RDB 恢复快但可能丢数据AOF 数据安全但恢复慢能否鱼与熊掌兼得Redis 4.0 引入了混合持久化完美融合了二者的优点。4.1 混合持久化原理混合持久化在 AOF 重写时生效。重写出的新 AOF 文件不是纯命令而是两部分组成┌─────────────────────────────────────┐ │ RDB 格式的二进制数据 │ ← 重写瞬间的内存快照 │ 占文件前半部分 │ ├─────────────────────────────────────┤ │ AOF 格式的增量命令 │ ← 重写过程中新产生的命令 │ 占文件后半部分 │ └─────────────────────────────────────┘前半部分是 RDB 格式包含了重写时刻的全部数据体积小加载快。后半部分是 AOF 命令记录了重写过程中新增的数据修改。重启加载时Redis 先读 RDB 部分快速恢复大部分数据再回放少量 AOF 增量命令既快又完整。4.2 开启混合持久化# redis.confRedis 4.0 支持aof-use-rdb-preambleyes查看并设置127.0.0.1:6379CONFIG GET aof-use-rdb-preamble1)aof-use-rdb-preamble2)yes127.0.0.1:6379CONFIG SET aof-use-rdb-preambleyesOKPython 中检查和触发 AOF 重写importredis rredis.Redis(decode_responsesTrue)# 查看混合持久化是否开启preambler.config_get(aof-use-rdb-preamble)[aof-use-rdb-preamble]print(f混合持久化: {开启 if preamble yes else 关闭})# 查看 AOF 信息infor.info(persistence)print(fAOF 开启: {info[aof_enabled]})print(fAOF 当前大小: {info[aof_current_size]} bytes)print(fAOF 基础大小: {info[aof_base_size]} bytes)# 手动触发 AOF 重写r.bgrewriteaof()print(已触发 BGREWRITEAOF)4.3 混合持久化的优缺点✅优点恢复速度快RDB 部分加载快附加少量 AOF 回放。数据完整AOF 增量保证了重写期间的数据不丢失。文件体积可控每次重写生成新文件比纯 AOF 更小。❌缺点可读性降低文件前部分是二进制不能直接cat查看。兼容性仅 Redis 4.0 支持老版本无法读取混合格式。生产推荐同时开启 RDB 和 AOF开启混合持久化。这是目前最广泛使用也是最稳妥的方案。5. 备份恢复策略5.1 数据备份无论 RDB 还是 AOF都应该定期将持久化文件备份到其他存储介质云存储、NAS、异地机器。# 备份 RDB 文件cp/data/redis/dump.rdb /backup/redis/dump_$(date%Y%m%d_%H%M).rdb# 备份 AOF 文件cp/data/redis/appendonly.aof /backup/redis/aof_$(date%Y%m%d_%H%M).aofPython 自动化备份脚本配合 crontab 定时执行importredisimportshutilimportos from datetimeimportdatetime rredis.Redis(decode_responsesTrue)# 1. 触发 BGSAVE确保 RDB 是最新的r.bgsave()# 2. 获取 RDB 文件路径dir_pathr.config_get(dir)[dir]rdb_filer.config_get(dbfilename)[dbfilename]rdb_pathos.path.join(dir_path, rdb_file)# 3. 备份到指定目录加上时间戳backup_dir/backup/redisos.makedirs(backup_dir,exist_okTrue)timestampdatetime.now().strftime(%Y%m%d_%H%M%S)backup_pathos.path.join(backup_dir, fdump_{timestamp}.rdb)shutil.copy2(rdb_path, backup_path)print(f备份完成: {backup_path})print(f文件大小: {os.path.getsize(backup_path)} bytes)5.2 数据恢复恢复流程停止 Redis。将备份的持久化文件复制到 Redis 数据目录。启动 Redis它会自动加载持久化文件。# 1. 停止 Redisredis-clishutdown# 或 docker stop redis-lab# 2. 复制备份文件cp/backup/redis/dump_20260101_0300.rdb /data/redis/dump.rdb# 3. 重启 Redisredis-server /etc/redis/redis.conf# 或 docker start redis-lab⚠️ 如果同时存在dump.rdb和appendonly.aofRedis 优先加载 AOF 文件因为它通常数据更完整。5.3 AOF 文件修复如果 AOF 文件损坏导致 Redis 无法启动# Redis 自带修复工具redis-check-aof--fixappendonly.aof它会截断 AOF 文件到最后一个有效命令处舍弃尾部损坏部分。6. 实战Docker 环境配置持久化用 Docker 启动一个开启了 RDB AOF 混合持久化的 Redis# 创建本地目录用于挂载mkdir-p~/redis-data# 启动容器dockerrun-d\--nameredis-persist\-p6379:6379\-v~/redis-data:/data\redis:7.2 redis-server\--appendonlyyes\--appendfsynceverysec\--aof-use-rdb-preambleyes\--save9001\--save30010\--save6010000验证# 进入容器dockerexec-itredis-persist redis-cli127.0.0.1:6379CONFIG GET appendonly1)appendonly2)yes127.0.0.1:6379CONFIG GET aof-use-rdb-preamble1)aof-use-rdb-preamble2)yes# 写一些数据127.0.0.1:6379SETtestpersistenceOK# 查看持久化文件# 在宿主机ls -lh ~/redis-data/7. 选型决策树你的 Redis 用途是什么 │ ├── 纯缓存数据可重建 │ └── 关掉所有持久化性能极致 │ ├── 一般业务允许丢1分钟数据 │ └── 只开 RDB配置 save 规则 │ ├── 重要业务最多丢1秒 │ └── 开 AOF everysec定期 BGREWRITEAOF │ └── 核心业务几乎不能丢数据 ├── RDB AOF everysec ├── 开启混合持久化 └── 配合主从 定期异地备份8. 动手试试体验 RDB开启 Redis设置save 60 1写入若干键等待 60 秒观察dump.rdb的生成时间和大小。模拟宕机docker restart检查数据是否恢复。体验 AOF 重写循环写入 10 万条SET查看appendonly.aof文件大小。手动执行BGREWRITEAOF对比重写前后的文件大小。混合持久化对比分别用纯 AOF 和混合持久化方式写入同样的数据重写后对比文件大小和redis-benchmark恢复速度。模拟恢复删除 Redis 容器并重新创建挂载之前的持久化文件验证数据是否完整恢复。预期效果RDB 快照恢复后丢失快照后写入的数据AOF 恢复完整但慢混合持久化恢复快且数据完整。9. 总结本文我们深入了 Redis 持久化三大方案核心要点RDB 是“拍照”AOF 是“录像”混合是“先拍照再录像”。everysec是 AOF 写入策略的甜点。Redis 4.0 一律开启混合持久化。持久化文件要异地备份并定期演练恢复。持久化是 Redis 数据安全的基石。掌握了它你就懂得了如何在性能和安全之间游刃有余地取舍。下一章我们将进入 Redis 高可用架构的第一站——主从复制看如何通过多副本提高数据安全和读吞吐量。想了解更多还可以去各个平台搜索「IT策士」一起升级 IT 思维
Redis 从入门到精通：持久化RDB 与 AOF
IT策士 10余年一线大厂经验专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章助你少走弯路。Redis 以极致的性能著称核心原因之一就是所有数据都在内存中读写。但内存的特性是易失的——一旦断电或进程崩溃所有数据瞬间消失。如果 Redis 只做缓存还好数据丢了可以从数据库重新加载可当它承载着分布式锁、计数器、消息队列等关键业务数据时丢数据就是事故。因此Redis 提供了两种持久化机制将内存数据保存到磁盘RDB快照和AOF追加日志以及它们的结合体——混合持久化。本文带你彻底理解这三种方案的工作原理、配置方法、优缺点和实战策略让你面对“会不会丢数据”这类问题时从容作答。1. 为什么需要持久化先理清一个概念持久化不是“备份”而是数据从内存到磁盘的同步过程。它的价值体现在故障恢复进程崩溃或服务器重启后能恢复数据减少损失。数据迁移将 RDB/AOF 文件复制到另一台机器快速恢复整个数据集。冷备归档定期保存某一时刻的完整数据快照。当然持久化不是免费的——它消耗磁盘 I/O、CPU 和内存需要在性能和数据安全之间做权衡。理解每种方案的原理才能做出正确选择。2. RDBRedis Database—— 内存快照2.1 什么是 RDBRDB 就是在某个时间点把 Redis 中所有数据生成一份压缩的二进制快照文件默认名为dump.rdb保存到磁盘。可以把它理解为给 Redis 内存拍了一张“照片”这张照片就是当时全部数据的完整拷贝。2.2 RDB 的触发方式① 手动触发# 阻塞主进程直到保存完成生产环境禁用127.0.0.1:6379SAVE OK# 后台异步保存推荐127.0.0.1:6379BGSAVE Background saving startedSAVE在主进程中执行保存期间 Redis不能处理任何命令。数据量大时会严重阻塞绝对不要在生产环境使用。BGSAVEfork 一个子进程由子进程负责写入 RDB 文件主进程继续处理请求。这就是我们日常使用的命令。② 自动触发配置文件中设置打开redis.conf你会看到类似这样的配置# 格式save seconds changes# 含义在 N 秒内如果至少有 M 个键被修改就触发一次 BGSAVEsave9001# 900 秒15分钟内至少 1 个键被修改save30010# 300 秒5分钟内至少 10 个键被修改save6010000# 60 秒内至少 10000 个键被修改多条规则是或关系满足任意一条就触发。也可以清空save配置来禁用自动 RDB但BGSAVE手动触发仍有效。③ 其他自动触发场景主从复制时主节点自动执行BGSAVE生成 RDB 文件发给从节点。执行SHUTDOWN关闭 Redis 时如果没有开启 AOF会自动执行一次SAVE。执行FLUSHALL后如果配置了自动保存规则会触发一次 RDB生成空快照非常危险。2.3 RDB 工作原理BGSAVE 流程主进程 子进程 │ │ ├── fork()──────────────────│(写时复制共享内存页)│ │ ├── 继续处理客户端命令 ├── 遍历所有数据 │ ├── 写入临时 RDB 文件 │ ├── 完成后原子重命名为 dump.rdb │ └── 退出 │ │ └── 子进程结束主进程继续服务关键点fork()使用了操作系统的**写时复制Copy-On-Write**机制。fork 出的子进程和父进程共享同一块物理内存只有当父进程修改数据时操作系统才会把对应的内存页复制一份。这样既保证了子进程能看到 fork 瞬间的完整数据又不会过度占用内存。⚠️ 如果 fork 后父进程写入量很大会导致大量内存页被复制内存占用可能短时间内翻倍。这也是为什么 Redis 需要预留一半内存的原因之一。2.4 RDB 配置详解# redis.conf# RDB 文件名dbfilename dump.rdb# RDB 文件保存路径需确保 Redis 有写权限dir/data/redis# 保存规则前面已介绍save9001save30010save6010000# 写入错误时是否停止接受写入建议 yesstop-writes-on-bgsave-erroryes# 是否压缩 RDB 文件CPU 换磁盘空间rdbcompressionyes# 是否对 RDB 文件做完整性校验rdbchecksumyesPython 中查看持久化配置importredis rredis.Redis(decode_responsesTrue)# 查看 RDB 相关配置forkeyin[dbfilename,dir,rdbcompression,rdbchecksum]: print(f{key}: {r.config_get(key)[key]})# 手动触发 BGSAVEresultr.bgsave()print(fBGSAVE 是否触发: {result})# 查看最近一次 BGSAVE 是否成功返回 Unix 时间戳last_saver.lastsave()print(f上次成功保存时间: {last_save})输出示例dbfilename: dump.rdb dir: /data rdbcompression:yesrdbchecksum:yesBGSAVE 是否触发: True 上次成功保存时间:17180928002.5 RDB 的优缺点✅优点文件紧凑单一压缩二进制文件非常适合冷备和灾难恢复。恢复速度快直接加载二进制数据到内存比逐条回放 AOF 快得多。性能影响小BGSAVE由子进程完成主进程只负责 fork不影响正常请求处理。适合主从同步主从复制首次全量同步直接传 RDB 文件。❌缺点会丢数据两次 RDB 之间的数据没来得及持久化一旦宕机就丢失。大数据量时 fork 代价高内存越大fork 越慢毫秒到秒级可能阻塞主进程。写时复制导致内存压力频繁写入时内存占用可能暴涨。3. AOFAppend Only File—— 命令日志3.1 什么是 AOFAOF 记录的是每一条修改数据的 Redis 命令写入、删除、修改按时间顺序追加到日志文件中。重启时Redis 通过逐条回放 AOF 中的命令来重建数据。可以把它理解为不是给数据拍照而是记录下了“拍照后发生的每一条改动”。3.2 AOF 的开启与基本配置# redis.confappendonlyyes# 开启 AOFappendfilenameappendonly.aof# AOF 文件名dir/data/redis# 存放目录与 RDB 共用重启 Redis 后用redis-cli观察127.0.0.1:6379SET nameIT策士OK127.0.0.1:6379SET age30OK127.0.0.1:6379INCR counter(integer)1查看 AOF 文件内容通过 Docker 进入容器或直接在服务器上$cat/data/appendonly.aof *3$3SET$4name$8IT策士 *3$3SET$3age$230*2$4INCR$7counterAOF 文件是 Redis 协议格式的纯文本可读可解析。如果误操作FLUSHALL还可以手动编辑 AOF 文件删除那条命令然后恢复数据仅限紧急情况。3.3 AOF 写入策略appendfsyncRedis 提供三种写入磁盘的策略由appendfsync配置# 每次写命令都同步到磁盘最安全但最慢appendfsync always# 每秒同步一次默认性能与安全的最佳平衡appendfsync everysec# 完全依赖操作系统缓冲区刷新最快但可能丢大量数据appendfsync no为什么everysec是最佳平衡Redis 主线程负责将 AOF 写入内存缓冲区然后由单独的 AOF 刷盘线程每秒执行一次fsync系统调用将缓冲区数据真正写入磁盘。主线程不参与实际的磁盘写入所以对性能影响极小。1 秒的数据丢失窗口对于绝大多数互联网场景是可接受的。3.4 AOF 重写Rewrite—— 防止文件无限膨胀AOF 会不断追加命令文件大小必然持续增长。假设一个计数器INCR了 100 次AOF 里会有 100 条INCR命令而实际上恢复数据只需要最后的值。AOF 重写就是 Redis 自己创建一个新的 AOF 文件只包含重建当前数据集所需的最少命令。# 手动触发重写127.0.0.1:6379BGREWRITEAOF Background append onlyfilerewriting started自动重写配置# 当 AOF 文件体积比上次重写后增长了 100%且超过 64MB 时自动触发重写auto-aof-rewrite-percentage100auto-aof-rewrite-min-size 64mb重写流程主进程 子进程 │ │ ├── fork()──────────────────────│ │ ├── 读取数据库数据 │ ├── 生成新 AOF 文件最小命令集 │ └── 退出 ├── 期间的新命令同时写入 │ ├── 旧 AOF 缓冲区正常 AOF │ └── AOF 重写缓冲区记录增量 │ └── 子进程完成后将重写缓冲区的增量写入新 AOF然后原子替换旧 AOF这个过程与 RDB 的BGSAVE非常类似利用子进程和写时复制主进程几乎不受影响。3.5 AOF 相关配置总览# 开启 AOFappendonlyyes# 文件路径appendfilenameappendonly.aof# 写入策略appendfsync everysec# 重写期间是否继续同步旧 AOFyes 保证安全但可能阻塞no-appendfsync-on-rewrite no# 自动重写触发条件auto-aof-rewrite-percentage100auto-aof-rewrite-min-size 64mb# AOF 文件尾部损坏时是否允许启动yes 会忽略尾部错误尝试恢复aof-load-truncatedyes3.6 AOF 的优缺点✅优点数据更安全everysec最多丢 1 秒数据always完全不丢。可读性好AOF 文件是 Redis 协议文本可直接查看和编辑。自动重写防止文件无限增长保持文件体积可控。❌缺点恢复速度慢重新回放所有命令大数据量时远比 RDB 慢。文件体积大相同数据集AOF 文件通常比 RDB 大。写入性能有损耗即使everysec每秒刷盘也会消耗 I/O。4. 混合持久化 —— Redis 4.0 的最佳方案既然 RDB 恢复快但可能丢数据AOF 数据安全但恢复慢能否鱼与熊掌兼得Redis 4.0 引入了混合持久化完美融合了二者的优点。4.1 混合持久化原理混合持久化在 AOF 重写时生效。重写出的新 AOF 文件不是纯命令而是两部分组成┌─────────────────────────────────────┐ │ RDB 格式的二进制数据 │ ← 重写瞬间的内存快照 │ 占文件前半部分 │ ├─────────────────────────────────────┤ │ AOF 格式的增量命令 │ ← 重写过程中新产生的命令 │ 占文件后半部分 │ └─────────────────────────────────────┘前半部分是 RDB 格式包含了重写时刻的全部数据体积小加载快。后半部分是 AOF 命令记录了重写过程中新增的数据修改。重启加载时Redis 先读 RDB 部分快速恢复大部分数据再回放少量 AOF 增量命令既快又完整。4.2 开启混合持久化# redis.confRedis 4.0 支持aof-use-rdb-preambleyes查看并设置127.0.0.1:6379CONFIG GET aof-use-rdb-preamble1)aof-use-rdb-preamble2)yes127.0.0.1:6379CONFIG SET aof-use-rdb-preambleyesOKPython 中检查和触发 AOF 重写importredis rredis.Redis(decode_responsesTrue)# 查看混合持久化是否开启preambler.config_get(aof-use-rdb-preamble)[aof-use-rdb-preamble]print(f混合持久化: {开启 if preamble yes else 关闭})# 查看 AOF 信息infor.info(persistence)print(fAOF 开启: {info[aof_enabled]})print(fAOF 当前大小: {info[aof_current_size]} bytes)print(fAOF 基础大小: {info[aof_base_size]} bytes)# 手动触发 AOF 重写r.bgrewriteaof()print(已触发 BGREWRITEAOF)4.3 混合持久化的优缺点✅优点恢复速度快RDB 部分加载快附加少量 AOF 回放。数据完整AOF 增量保证了重写期间的数据不丢失。文件体积可控每次重写生成新文件比纯 AOF 更小。❌缺点可读性降低文件前部分是二进制不能直接cat查看。兼容性仅 Redis 4.0 支持老版本无法读取混合格式。生产推荐同时开启 RDB 和 AOF开启混合持久化。这是目前最广泛使用也是最稳妥的方案。5. 备份恢复策略5.1 数据备份无论 RDB 还是 AOF都应该定期将持久化文件备份到其他存储介质云存储、NAS、异地机器。# 备份 RDB 文件cp/data/redis/dump.rdb /backup/redis/dump_$(date%Y%m%d_%H%M).rdb# 备份 AOF 文件cp/data/redis/appendonly.aof /backup/redis/aof_$(date%Y%m%d_%H%M).aofPython 自动化备份脚本配合 crontab 定时执行importredisimportshutilimportos from datetimeimportdatetime rredis.Redis(decode_responsesTrue)# 1. 触发 BGSAVE确保 RDB 是最新的r.bgsave()# 2. 获取 RDB 文件路径dir_pathr.config_get(dir)[dir]rdb_filer.config_get(dbfilename)[dbfilename]rdb_pathos.path.join(dir_path, rdb_file)# 3. 备份到指定目录加上时间戳backup_dir/backup/redisos.makedirs(backup_dir,exist_okTrue)timestampdatetime.now().strftime(%Y%m%d_%H%M%S)backup_pathos.path.join(backup_dir, fdump_{timestamp}.rdb)shutil.copy2(rdb_path, backup_path)print(f备份完成: {backup_path})print(f文件大小: {os.path.getsize(backup_path)} bytes)5.2 数据恢复恢复流程停止 Redis。将备份的持久化文件复制到 Redis 数据目录。启动 Redis它会自动加载持久化文件。# 1. 停止 Redisredis-clishutdown# 或 docker stop redis-lab# 2. 复制备份文件cp/backup/redis/dump_20260101_0300.rdb /data/redis/dump.rdb# 3. 重启 Redisredis-server /etc/redis/redis.conf# 或 docker start redis-lab⚠️ 如果同时存在dump.rdb和appendonly.aofRedis 优先加载 AOF 文件因为它通常数据更完整。5.3 AOF 文件修复如果 AOF 文件损坏导致 Redis 无法启动# Redis 自带修复工具redis-check-aof--fixappendonly.aof它会截断 AOF 文件到最后一个有效命令处舍弃尾部损坏部分。6. 实战Docker 环境配置持久化用 Docker 启动一个开启了 RDB AOF 混合持久化的 Redis# 创建本地目录用于挂载mkdir-p~/redis-data# 启动容器dockerrun-d\--nameredis-persist\-p6379:6379\-v~/redis-data:/data\redis:7.2 redis-server\--appendonlyyes\--appendfsynceverysec\--aof-use-rdb-preambleyes\--save9001\--save30010\--save6010000验证# 进入容器dockerexec-itredis-persist redis-cli127.0.0.1:6379CONFIG GET appendonly1)appendonly2)yes127.0.0.1:6379CONFIG GET aof-use-rdb-preamble1)aof-use-rdb-preamble2)yes# 写一些数据127.0.0.1:6379SETtestpersistenceOK# 查看持久化文件# 在宿主机ls -lh ~/redis-data/7. 选型决策树你的 Redis 用途是什么 │ ├── 纯缓存数据可重建 │ └── 关掉所有持久化性能极致 │ ├── 一般业务允许丢1分钟数据 │ └── 只开 RDB配置 save 规则 │ ├── 重要业务最多丢1秒 │ └── 开 AOF everysec定期 BGREWRITEAOF │ └── 核心业务几乎不能丢数据 ├── RDB AOF everysec ├── 开启混合持久化 └── 配合主从 定期异地备份8. 动手试试体验 RDB开启 Redis设置save 60 1写入若干键等待 60 秒观察dump.rdb的生成时间和大小。模拟宕机docker restart检查数据是否恢复。体验 AOF 重写循环写入 10 万条SET查看appendonly.aof文件大小。手动执行BGREWRITEAOF对比重写前后的文件大小。混合持久化对比分别用纯 AOF 和混合持久化方式写入同样的数据重写后对比文件大小和redis-benchmark恢复速度。模拟恢复删除 Redis 容器并重新创建挂载之前的持久化文件验证数据是否完整恢复。预期效果RDB 快照恢复后丢失快照后写入的数据AOF 恢复完整但慢混合持久化恢复快且数据完整。9. 总结本文我们深入了 Redis 持久化三大方案核心要点RDB 是“拍照”AOF 是“录像”混合是“先拍照再录像”。everysec是 AOF 写入策略的甜点。Redis 4.0 一律开启混合持久化。持久化文件要异地备份并定期演练恢复。持久化是 Redis 数据安全的基石。掌握了它你就懂得了如何在性能和安全之间游刃有余地取舍。下一章我们将进入 Redis 高可用架构的第一站——主从复制看如何通过多副本提高数据安全和读吞吐量。想了解更多还可以去各个平台搜索「IT策士」一起升级 IT 思维
