rdb快照无法实现零数据丢失，因其本质是离散时间点的全量备份，两次快照间的所有变更均无法捕获；自动或手动bgsave均不能缩短rpo，且存在fork盲区与一致性窗口期。
RDB快照天生不是为实时备份设计的，它只能保存某个时间点的全量状态，两次快照之间的所有变更都无法捕获——这不是配置能绕过的限制，而是机制决定的。
为什么 RDB 的 save 60 10000 配置无法消除数据丢失
RDB 的自动触发规则（如 save 60 10000）只决定“是否启动一次 BGSAVE”，不保证“数据写入即落盘”。从上一次快照结束，到下一次快照开始前的任意时刻宕机，中间所有写操作都会丢失。
- 即使把配置改成
save 1 1，也做不到每秒持久化：因为BGSAVE本身有执行耗时，且 Redis 不会在上一个快照未完成时启动下一个 - 频繁触发
BGSAVE会显著增加 fork 开销和磁盘 I/O，尤其当内存数据超 4GB 后，fork 可能卡住主进程几十毫秒 - 配置项只影响触发时机，不改变“快照是离散事件”这一本质——它不是流式写入，没有“赶上就存一下”的能力
手动执行 BGSAVE 也不能替代实时同步
BGSAVE 是异步的，但它的异步性只解决“阻塞问题”，不解决“时效问题”。它生成的是执行时刻的快照，而非命令提交时刻的状态。
- 客户端执行
SET key value成功返回后，该 key 仍只存在于内存，BGSAVE是否已运行、何时运行、是否已完成，完全不可控 - 若在
BGSAVE子进程 fork 完成前发生崩溃，连刚写入的数据都可能因页表未复制而丢失（写时复制机制的边界情况） - 运维脚本定时调用
redis-cli bgsave并不能缩短 RPO（恢复点目标），RPO 始终等于上一次成功快照距宕机的时间差
RDB 文件生成过程中的数据一致性盲区
RDB 文件写入期间，Redis 主进程仍在接受写请求，而子进程看到的数据是 fork 时刻的内存副本。这导致一个关键盲区：新写入的数据既不在旧快照里，也不在正在生成的新快照里。
- 例如：t=0s 时开始
BGSAVE；t=0.2s 时客户端写入key1；t=0.5s 时 Redis 崩溃——key1永久丢失，因为它没被任何一份 RDB 覆盖 - 这种“窗口期”无法通过调整
rdbcompression或rdbchecksum缩短，它们只影响文件生成后的处理，不影响快照时间点的选择 - 跨版本恢复时，如果新写入的数据结构恰好触发了旧版 RDB 解析器的兼容性 bug，还可能造成静默损坏，而非报错失败
真正需要接近零丢失的场景，必须放弃纯 RDB 思路——要么启用 AOF 的 appendfsync everysec 或 always，要么直接使用 Redis 6.0+ 的混合持久化（aof-use-rdb-preamble yes），把 RDB 快照作为 AOF 日志的初始基线。快照永远只是快照，它不承诺“最后一条命令”的存在。
