全量备份应选RDB因其文件小、恢复快适合作为每日基线备份而AOF仅宜作为增量补丁不可替代RDB承担全量角色。全量备份选 RDB 还是 AOF得看恢复速度和磁盘压力RDB 是快照式备份save 或 bgsave 生成的 dump.rdb 文件小、恢复快适合做每日基线备份AOF 记录每条写命令体积大、恢复慢但数据丢失少——它不适合当“全量”用只该作为增量补丁存在。企业级策略里rdb 是主干aof 是毛细血管。线上 Redis 实例内存 4GB 时bgsave 可能触发 fork 延迟需监控 latest_fork_usecappendonly yes 开启后aof_rewrite 会自动压缩 AOF但重写期间仍写旧 AOF 文件磁盘空间可能瞬时翻倍不要把 save 配置成 save 1 1 这类高频策略小概率写入抖动也会触发 RDB加重 fork 压力怎么让 AOF 真正变成“可落地”的增量备份AOF 默认是追加写但直接 rsync 或 cp 正在写的 appendonly.aof 文件大概率损坏——因为文件末尾可能是半条命令。必须靠 Redis 自身机制切出干净片段。用 bgrewriteaof 触发重写完成后 Redis 会原子替换 AOF 文件新文件可安全归档配合 CONFIG SET appendfilename appendonly-$(date %s).aof 动态改名需提前在 config 中启用 appendfilename 可写再执行 bgrewriteaof就能按时间戳分片存档别依赖 fsync always它让每次写都落盘QPS 掉 3–5 倍fsync everysec 是平衡点最多丢 1 秒数据但吞吐稳定备份文件放哪本地磁盘只是中转站所有备份文件dump.rdb、appendonly-*.aof必须离开 Redis 所在机器。本地磁盘故障是单点且备份过程本身会争抢 I/O。 RedClaw 百度推出的手机端万能AI Agent助手