结论：对于大多数场景，推荐使用RDB结合AOF的混合持久化策略：RDB每5-10分钟快照一次（fsync policy everysec），AOF开启no-appendfsync，数据丢失风险控制在秒级，性能开销仅5-10%；高可靠性需求用AOF everysec，接受1秒丢失；超高性能场景纯内存+主从读写分离，数据丢失风险转移到业务层。实际部署时，先基准测试fork时间，结合业务RPO/RTO需求选择。

来源1

Redis持久化有两个主要方式：RDB（Redis DataBase）和AOF（Append Only File）。RDB是把内存中的数据集快照以二进制的方式写入磁盘，AOF是对每次写操作记录日志。RDB优点是文件紧凑，恢复快；缺点是fork进程耗时长，可能丢失最后一次快照后的数据。AOF优点是数据丢失少，可靠性高；缺点是文件大，重写耗时。实际选择要看数据丢失容忍度和性能要求。

来源2

数据丢失风险：RDB的fsync策略有三种：always（每次同步，性能差）、everysec（每秒，推荐）、no（OS决定，最快但风险高）。纯RDB模式下，重启丢失最后一次bgsave的数据，通常几分钟量级。AOF的no-appendfsync-on-rewrite可将后台重写时的数据丢失控制在1秒内。混合模式RDB+AOF是最佳实践，前者用于快速重启，后者保证数据完整性。

来源3

性能瓶颈主要在fork和fsync。RDB的bgsave fork过程在数据量大时可能阻塞主进程几秒到几十秒，期间QPS下降。AOF append操作如果everysec，平均延迟1ms，但峰值高时磁盘I/O瓶颈明显。测试显示，开启AOF后写QPS下降20-30%，RDB save 900 1仅5%。解决方案：SSD磁盘、调整save策略、开启AOF重写自动化。

来源4

权衡方法：1）计算RPO（Recovery Point Objective），如能接受1分钟丢失用RDB everysec；2）基准fork时间，>1s则优化内存分配或用AOF；3）主从复制+RDB，slave负责持久化，主节点内存模式；4）云Redis服务默认混合模式，用户无需配置。实际案例：电商秒杀用纯内存+Sentinel，日志系统用AOF。

来源5

混合持久化配置：appendonly yes，auto-aof-rewrite-percentage 100，auto-aof-rewrite-min-size 64mb，save 900 1 300 10 60 10000。重启时优先加载AOF，AOF坏了用RDB。这样数据丢失最小，恢复速度最快。性能影响：CPU+5%，磁盘I/O增加但异步不阻塞。

来源6

风险场景：高峰期bgsave触发，主进程fork阻塞导致请求超时。监控fork_time_us指标，>500ms报警。AOF重写时内存峰值翻倍，需预留。解决方案：业务分片多实例、读写分离、AOF用no-appendfsync-off（Redis 7.0新特性）。

FAQ
Q: RDB和AOF哪个丢失数据少？
A: AOF everysec最多丢1秒，RDB取决于save间隔，通常几分钟。
Q: 性能影响多大？
A: RDB+AOF混合约5-15% QPS下降，SSD下可忽略。
Q: 怎么监控持久化效果？
A: 用INFO persistence看rdb_changes_since_last_save、aof_current_size。
Q: 内存不够怎么持久化？
A: 开启maxmemory-policy allkeys-lru，主从分离持久化到slave。