rdb快照本质是异步全量快照，非wal日志；它仅在满足配置条件（如save 60 10000）或执行bgsave时，通过fork子进程将当前内存数据序列化写入临时文件，两次快照间的数据变更不落盘，存在丢失风险。
RDB 快照本质是异步快照，不是 WAL 日志
Redis 的 RDB 不是像 MySQL 的 redo log 那样逐条记录修改、实时刷盘的机制。它只在满足条件（如 save 60 10000）或手动执行 bgsave 时，才 fork 子进程把当前内存全量数据序列化写入临时文件。这个过程本身有延迟，且两次快照之间所有写操作都不落盘——哪怕只差 1 秒宕机，这 1 秒的数据就丢了。
常见错误现象：
- 配置了
save 60 10000，但业务每秒写入 2000 次，实际可能 30 秒就触发一次，也可能 65 秒才触发，不可控 - 执行
bgsave失败后，若stop-writes-on-bgsave-error为yes（默认），后续写命令直接报MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk - fork 耗时随内存增长而显著上升：10GB 内存实例 fork 可能卡住 200ms+，期间主线程仍可写，但快照内容已不反映最新状态
AOF 的 appendfsync everysec 也不是实时提交
即使开启 AOF，appendfsync everysec（默认）也只是把命令缓冲区每秒刷一次盘，并非每次 SET 都调用 fsync()。Linux 内核会把写请求暂存在 page cache，真正落 SSD 还有延迟；更关键的是，如果系统在 write() 后、fsync() 前崩溃，这一秒的命令就丢失了。
使用场景差异：
- MySQL 的
redo log是预写式日志（WAL），先写日志再改内存页，且支持innodb_flush_log_at_trx_commit=1强制每次事务都fsync，这是持久性（Durability）的工程实现基础 - Redis 的设计目标是低延迟响应，不是强一致主库，所以它把「写完即成功」作为默认语义，持久化只是后台尽力而为的保障手段
- 混合持久化（
aof-use-rdb-preamble yes）虽能兼顾启动速度和数据安全，但仍是 AOF 文件开头嵌一段 RDB，无法改变命令追加的本质延迟
真正影响恢复完整性的不是“有没有日志”，而是“日志是否强制同步”和“是否与写操作原子绑定”
Redis 的 AOF 在 appendfsync always 模式下确实每次写都 fsync，但代价是吞吐暴跌 3–5 倍，且仍不保证原子性：比如一条 LPUSH 命令被拆成多段写入（因协议解析或缓冲区切分），崩溃可能留下半截命令，导致 AOF 重放失败。
容易被忽略的关键点：
- RDB 和 AOF 都不提供事务级原子性保障——一个
multi/exec块里的多条命令，AOF 只记录原始命令，不记录事务边界；崩溃后重放可能只执行前几条 - 没有 checkpoint 机制：MySQL 的
checkpoint会定期把脏页刷盘并更新redo log起始位，Redis 没有类似概念，AOF 重放必须从头开始 - 磁盘 I/O 调度和文件系统缓存行为（如 ext4 的
data=ordered）会进一步模糊“什么算真正落盘”，这点连 Redis 自身也无法控制
