当Redis进程意外崩溃或服务器宕机时，内存中的数据可能全部丢失。为了避免这种灾难，Redis提供了两种持久化机制：RDB持久化（快照）和AOF日志（追加式文件）。但很多人在配置时纠结：到底该用哪种？它们有什么区别？如何组合才能达到最佳备份恢复效果？本文将从实际问题切入，对比两种机制，并给出操作建议。
RDB持久化：定时快照的利与弊
RDB持久化通过生成数据集的二进制快照来保存某个时间点的全量数据。默认配置下，Redis会在满足条件时（如900秒内至少1次写操作）自动触发BGSAVE命令，fork子进程将数据写入临时文件，然后替换之前的RDB文件。
优点很明显：文件紧凑，适合备份和灾难恢复，恢复速度远快于AOF。但缺点也致命：如果Redis在两次快照之间崩溃，这段时间的写入数据就会丢失。例如，你配置了“900秒内1次写操作”才保存，那么在崩溃前900秒内的所有写入都可能丢失。
AOF日志：记录每次写操作的持久化
AOF（Append Only File）以日志形式记录每个写操作，重启时通过重放日志来恢复数据。它的持久化策略更灵活，可以通过appendfsync配置控制同步频率：always（每次写都同步）、everysec（每秒同步）、no（由操作系统决定）。
如果使用everysec，最多丢失1秒的数据，远优于RDB。但AOF文件通常更大，恢复速度也慢。此外，AOF可能因日志重写（rewrite）或损坏而需要额外处理。
选择与组合：根据业务容忍度决定
实际项目中，很少只用一种。常见做法是同时开启RDB和AOF，让AOF保证数据安全，RDB用于快速恢复和备份。但要注意，Redis重启时会优先加载AOF文件，因为AOF的数据更完整。
如果你的业务能容忍几分钟的数据丢失，可以只使用RDB，简化运维。如果数据至关重要，建议开启AOF并设置everysec，同时保留RDB作为备份。Redis官方文档也建议两者结合使用。
操作步骤：配置与触发备份
要开启RDB，在redis.conf中设置save参数，例如：
save 900 1
save 300 10
save 60 10000开启AOF，设置appendonly yes，并配置appendfsync everysec。手动触发备份时，可以使用BGSAVE命令生成RDB快照，或使用BGREWRITEAOF对AOF进行重写。
恢复时，只需将备份文件（dump.rdb或appendonly.aof）放到Redis的工作目录，启动后自动加载。注意，如果文件损坏，恢复会失败，因此定期验证备份文件的完整性很重要。
常见误区与失败条件
误区一：认为AOF开启后RDB就没用了。实际上，RDB文件是很好的离线备份，AOF更适合实时恢复。误区二：将RDB保存间隔设置过长，导致数据丢失风险增大。误区三：忽视AOF重写，导致文件无限增长。
失败条件包括：磁盘空间不足导致BGSAVE失败；AOF文件损坏且没有备份；在恢复时使用了错误的配置文件导致加载失败。因此，备份文件应定期测试恢复，确保可用。
结合日志管理实践
持久化文件是Redis的“日志”，但系统层面的日志管理同样重要。根据OWASP的日志安全速查表，日志记录应包含安全事件，并保持一致性。虽然这是针对应用日志，但Redis的慢查询日志和运行日志也建议开启，便于排查问题。
OpenTelemetry日志规范指出，日志与其他遥测信号（如trace）的关联性很弱，但Redis的持久化文件与监控指标结合，能更全面地了解数据状态。
总结与建议
RDB持久化和AOF日志各有优劣，没有绝对的最好，只有最适合你的业务场景。建议：
- 数据重要且不能丢失：开启AOF，设置everysec，并定期重写。
- 追求恢复速度：使用RDB，但接受可能的数据丢失。
- 最佳实践：两者结合，并定期测试恢复流程。
最后，不要忘记备份文件的异地存储和恢复演练，这是数据库备份恢复的最后一道防线。
参考资料
延伸阅读