rdb持久化必然存在数据丢失窗口，丢失量取决于save配置与实际写入频率的匹配程度；save 60 10000仅在60秒内≥10000次写时触发，若写入稀疏或差1次达标即全丢，且bgsave返回ok不表示落盘成功。
Redis RDB 持久化一定会丢失数据，丢失量取决于 save 参数配置与实际写入频率的匹配程度——不是“会不会丢”，而是“最多丢多久的数据”。
save 60 10000 这类配置的实际丢失窗口有多大
这个配置只在满足“60 秒内发生 ≥10000 次写操作”时才触发一次 bgsave。如果业务写入稀疏（比如每分钟只写 500 次），那它永远不会触发；如果写入集中但不达标（比如 59 秒内写了 9999 次），随后宕机，就丢失全部这 59 秒数据。
-
save是“累积计数+时间窗口”双条件，缺一不可，不是“每 60 秒检查一次” - Redis 不会记录“上次快照后写了多少次”，只在每次写命令执行时递增计数器，并在每次检查周期开始时重置计数器
- 若配置了多组
save（如save 900 1、save 300 10、save 60 10000），只要任意一组满足即触发，但它们之间无优先级，也无兜底逻辑
为什么 bgsave 返回 OK 不代表数据已落盘
bgsave 成功返回仅表示子进程已 fork 并开始工作，不保证文件写完、不保证原子覆盖、更不保证刷盘。常见风险点：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 子进程写入临时
.rdb文件过程中，若磁盘满或系统 OOM kill 掉子进程，生成的文件可能损坏或截断 - 新文件用
rename()原子替换旧文件，但 rename 本身不触发 fsync；若刚 rename 完就断电，新文件可能只存在于 page cache 中 -
stop-writes-on-bgsave-error no（默认）会让 Redis 在bgsave失败后继续接收写请求，而你完全感知不到这次失败
如何用监控和日志判断 RDB 是否真正在起作用
不能只看配置是否存在，必须验证其是否被真实触发并成功落地：
- 定期执行
redis-cli info persistence | grep -E "(rdb_changes_since_last_save|rdb_bgsave_in_progress|rdb_last_bgsave_status)"，关注rdb_changes_since_last_save是否长期不归零（说明没触发）、rdb_last_bgsave_status是否为ok - 检查
redis.log中是否有Background saving started by pid和后续的DB saved on disk，缺失后者即保存失败 - 用
stat命令查dump.rdb文件的mtime和size变化，确认它确实在更新，而非空文件或大小恒为 0 - 注意：
save ""是显式禁用所有自动 RDB，比注释掉更危险，且redis-cli config get save会返回空字符串，容易被忽略
RDB 的本质是“尽力而为的快照”，它的丢失窗口不是固定秒数，而是由业务写模式、配置粒度、系统稳定性共同决定的连续变量。最常被忽略的一点是：即使 save 配得再密，只要 AOF 关闭且没有外部备份机制，任何一次未完成的 bgsave 或覆盖失败，都会让整个持久化链条失效。
