会丢，且丢失量取决于save配置策略与故障时间点；rdb是定时快照而非实时落盘，进程意外退出、断电或误重启时，上次快照后所有写入均丢失。
会丢，而且丢多少取决于 save 配置项的策略和故障发生的时间点。
RDB 丢失数据的典型场景
RDB 是定时快照，不是实时落盘。只要 Redis 进程意外退出、服务器断电或运维误重启，而此时距离上一次成功生成 dump.rdb 已过去一段时间，中间所有写入就全丢了。
- 配置
save 900 1：900 秒（15 分钟）内只要有 1 次 key 变更就触发快照 → 最多丢 15 分钟数据 - 配置
save 60 10000：60 秒内发生 10000 次变更才触发 → 若写入稀疏，可能几小时都不触发，丢得更多 - 手动执行
SAVE：主进程阻塞，期间请求失败，且一旦中断（如超时或 OOM），dump.rdb可能写坏或不完整 - 使用
BGSAVE：虽不阻塞，但若子进程 fork 失败（内存不足、ulimit 限制）、磁盘满或写入中途崩溃，快照仍会失败，且无自动重试
为什么 RDB 不保证“最后一次操作”安全
RDB 文件只保存某一时刻的**最终数据状态**，它不记录命令、不跟踪增量、不校验写入完成性。哪怕你刚执行完 SET user:1001 "online"，只要还没到快照触发条件或 BGSAVE 没跑完，这个值就不在磁盘上。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- fork 子进程时会复制父进程页表，如果内存大（比如 20GB+），fork 耗时可能达数百毫秒，期间写入仍在继续，但子进程看到的是 fork 那一瞬的内存副本
-
dump.rdb写入是原子替换：先写临时文件，再rename。但如果 rename 前进程被 kill，临时文件残留，下次启动不会加载它 - Redis 启动时只认当前目录下的
dump.rdb，不会自动合并多个历史快照，也不会告警“上次快照是 3 小时前”
哪些配置会让 RDB 更容易丢数据
看似“省资源”的配置，实际放大了丢失窗口。生产环境常见踩坑点：
- 注释掉全部
save行 → 等价于关闭 RDB 自动持久化，只靠手动BGSAVE，基本等于没开 - 把
dir设为/tmp或其他易清空路径 → 重启后dump.rdb文件直接消失 - 未设置
stop-writes-on-bgsave-error yes→BGSAVE失败时 Redis 默认继续接受写入，但用户完全感知不到快照已失效 -
dbfilename被改成非默认名，但备份脚本仍只打包dump.rdb→ 灾备时发现备份文件根本不存在
RDB 的本质是“低频全量备份”，不是 WAL。想降低丢失风险，不能只调 save 参数频率，得正视它的设计边界：它从不承诺“最后一次写入”。真正要保最后一秒，必须配 AOF 或混合模式，并确认 appendfsync 是 everysec 还是 always —— 但那已是另一个机制的事了。
