AOF在默认配置下比RDB更可靠，因其appendfsync everysec策略最多丢失1秒数据，而RDB依赖定时快照可能丢失几分钟甚至十几分钟数据；但AOF的可靠性需配合磁盘、内核及运维保障，并非绝对不丢数据。
是的，AOF在默认配置下确实比RDB更可靠——但“更可靠”不等于“不丢数据”，它只意味着**最多丢失1秒写入**（appendfsync everysec），而RDB在默认配置下可能丢失**几分钟甚至十几分钟**的数据。
为什么AOF的可靠性更高？关键看appendfsync策略
AOF的可靠性不来自“记录所有命令”这个动作本身，而来自它如何把命令真正落盘。Redis提供三种同步策略：
-
always：每条写命令都调用fsync()，几乎不丢数据，但性能暴跌，IO成为瓶颈 -
everysec（默认）：命令先写入内核缓冲区，每秒fsync一次；宕机时最多丢失1秒缓冲区数据 -
no：完全交由操作系统决定刷盘时机，性能接近RDB，但可靠性大幅下降，可能丢数秒到数分钟
注意：everysec不是“每秒保存一次快照”，而是“每秒强制刷盘一次日志”。只要磁盘没坏、系统没崩溃到连缓冲区都清空，这1秒内的数据就还在内核缓冲里，能被恢复。
RDB的“丢失窗口”其实很难控制
RDB靠save规则触发快照，例如配置save 60 10000，意思是“60秒内至少10000次key变更才触发”。但问题在于：
- 如果业务写入稀疏（比如每分钟只改5个key），那可能几个小时都不生成新RDB文件
-
SAVE命令会阻塞主线程，生产环境禁用；BGSAVE虽不阻塞，但fork()在大内存实例上可能耗时数百毫秒，频繁调用反而影响稳定性 - 没有机制保证“最后一次快照一定包含最新数据”——它只反映
fork()那一刻的内存状态，之后的所有写入都不在快照里
换句话说，RDB的可靠性取决于你的业务写入节奏和配置是否匹配。而AOF的everysec是时间维度上的硬保障，与写入量无关。
但AOF的可靠性有隐藏代价
高可靠性不是免费的，AOF在以下环节容易出问题：
-
bgrewriteaof执行期间，新写入仍持续追加到旧AOF文件，若此时发生OOM或磁盘满，可能导致AOF文件损坏，Redis启动时拒绝加载（报错Bad file format reading the append only file） - AOF重写本身会占用CPU和磁盘IO，若配置
auto-aof-rewrite-percentage过低（如设为50%），小文件也会频繁重写，放大抖动 - 文本格式的AOF文件比二进制RDB更容易被人误编辑或注入非法命令，恢复时直接失败
所以AOF的“更可靠”是有条件的：它要求你监控aof_current_size和aof_base_size，及时干预重写，并确保磁盘空间充足、文件权限正确。
真正容易被忽略的是：AOF的可靠性优势只在“单节点故障恢复”场景成立。一旦涉及主从切换或集群分片，AOF日志的命令时序、复制偏移、重写一致性都会引入新的不确定性——这时候，混合持久化（aof-use-rdb-preamble yes）才是兼顾恢复速度与数据安全的务实选择。
