一句话Redis 数据在内存里断电就丢。RDB 是定期拍快照恢复快但可能丢数据AOF 是记录每条写命令数据安全但文件大恢复慢。生产推荐 RDB AOF 混合持久化。1. 为什么需要持久化Redis 是内存数据库 → 断电/宕机 → 数据全丢 持久化的目标把内存数据写到磁盘宕机后能恢复2. RDB快照原理在指定时间间隔内fork 一个子进程把内存中的数据集以二进制形式写入 dump.rdb 文件触发条件① 自动触发配置 save 规则 save 900 1 → 900秒内至少1次修改就触发 save 300 10 → 300秒内至少10次修改就触发 save 60 10000 → 60秒内至少10000次修改就触发 ② 手动触发 SAVE → 阻塞主线程不推荐 BGSAVE → fork 子进程不阻塞推荐优点与缺点优点 ✅ 文件紧凑体积小 ✅ 恢复速度快直接加载二进制文件 ✅ 适合备份和灾难恢复 缺点 ❌ 不是实时的两次快照之间的数据会丢失 ❌ fork 子进程时如果数据量大可能短暂卡顿3. AOF追加文件原理以日志形式记录服务器收到的每一条写命令 重启时通过重放replay这些命令来重建数据AOF 的三种同步策略策略说明数据安全性能always每条写命令都 fsync最好最多丢一条最差everysec每秒 fsync 一次推荐最多丢 1 秒数据折中no由操作系统决定何时 fsync可能丢较多数据最好AOF 重写AOF RewriteAOF 文件会越来越大因为记录了所有写命令 Redis 会定期对 AOF 文件进行瘦身——重写 重写不是读取旧 AOF 文件而是直接读取当前内存数据 用最少的命令重新生成一个新的 AOF 文件 触发 ① 自动配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size ② 手动BGREWRITEAOF优点与缺点优点 ✅ 数据安全性更高everysec 最多丢 1 秒 ✅ 日志文件可读即使损坏也能部分恢复 ✅ 兼容旧版本数据格式 缺点 ❌ 文件比 RDB 大 ❌ 恢复速度慢要逐条重放命令 ❌ everysec 模式下 fsync 会影响性能4. RDB vs AOF 对比对比维度RDBAOF数据安全可能丢数分钟数据最多丢 1 秒everysec文件大小小二进制压缩大记录所有写命令恢复速度快直接加载慢逐条重放对性能影响fork 时可能有短暂卡顿everysec 模式下有 fsync 开销适合场景备份、灾难恢复、数据容忍度高数据安全要求高5. 混合持久化推荐Redis 4.0 引入结合两者优势aof-use-rdb-preamble yes AOF 文件结构 前半部分 → RDB 格式的全量快照恢复快 后半部分 → 增量的 AOF 写命令数据安全 重启时 先快速加载 RDB 部分 → 再重放少量 AOF 命令 → 既快又安全 ✅6. 生产建议纯缓存场景丢数据无所谓 → 可以关闭持久化或者只开 RDB 做备份 数据存储场景不能丢数据 → RDB AOF 混合持久化推荐 → AOF 用 everysec 策略 注意持久化只保单机数据安全 磁盘坏了照样丢数据 → 还需要主从复制/集群 面试回答模板Redis 持久化有两种方式RDB 和 AOF。RDB 是定期对内存数据拍快照 生成 dump.rdb 二进制文件优点是文件小恢复快缺点是两次快照之间的数据 可能丢失。AOF 是以日志形式记录每一条写命令重启时通过重放命令重建数据 优点是数据安全性高everysec 模式最多丢 1 秒缺点是文件大恢复慢。 生产环境推荐用 Redis 4.0 的混合持久化AOF 文件前半部分是 RDB 格式的 全量快照后半部分是增量的 AOF 命令重启时先快速加载 RDB 部分再重放 少量命令既恢复快又保证数据安全。参考来源01_Raw【原始素材】/notion 资料/Notion/任务/Redis进阶二之Redis数据安全性分析.mdRedis 官方文档Persistence
