RDB、AOF 与数据安全

Redis 持久化只能降低进程重启后的数据损失，不能替代副本、异地备份和恢复演练。先定义 RPO、RTO 和 Redis 数据能否从数据库重建，再选择 RDB、AOF 或组合模式。

Table of contents

两种持久化记录什么

RDB 在某个时点生成数据快照，文件紧凑、加载通常较快，但两次快照之间的更新可能丢失。AOF 追加会改变数据集的命令，再通过重写压缩历史；它能缩小丢失窗口，但增加持续磁盘写入和恢复成本。

实验配置同时启用了：

appendonly yes
appendfsync everysec
save 60 1000

appendfsync everysec 通常表示由 Redis 周期性请求刷盘，故障时仍可能损失接近一个刷盘窗口的数据。操作系统、虚拟化和存储缓存也会影响真实持久性，不能只看配置名称。

Fork 与写时复制峰值

生成 RDB 或重写 AOF 时，Redis 通常创建子进程。Fork 后父子进程共享物理页；父进程继续写入时，操作系统复制被修改页，这叫 Copy-on-Write。写入密集时内存峰值和延迟可能上升，所以容量规划要保留持久化余量。

缓存和数据源的策略不同

纯缓存可以关闭持久化，但重启会形成集中回源，必须有限流、预热和数据库保护。会话、限额或任务状态若只存在 Redis，就已经不是“可丢缓存”，需要明确持久化、复制和业务恢复语义。

备份文件要复制到独立故障域、校验、加密并限制删除权限。恢复演练应启动新实例、加载文件、抽样校验 TTL 和关键数据，然后让应用做只读验收。

参考 Redis 持久化文档。

下一步

继续阅读07-05 主从、Sentinel 与 Cluster，把单节点数据安全扩展到故障转移和水平分片。