rdb_last_save_time是redis中唯一标识上一次rdb持久化成功完成时间的unix时间戳字段，需用date -d @（linux）或date -r （macos）转为可读时间；返回0表示从未成功生成rdb；其值与dump.rdb文件mtime存在1–3秒延迟属正常，因lastsave在原子rename前更新。

rdb_last_save_time 是 Redis 中唯一能直接告诉你“上一次 RDB 持久化成功完成时间”的字段，但它返回的是 Unix 时间戳（秒级），不是可读时间，也不能反映执行中或失败的状态。

怎么把 rdb_last_save_time 转成人类可读时间

直接用 redis-cli INFO persistence 查到的 rdb_last_save_time 是一个数字，比如 1719234567。要转成时间，得配合系统命令：

• Linux/macOS：用 date -d @1719234567（macOS 需改用 date -r 1719234567）
• 脚本里别写 redis-cli --raw LASTSAVE | xargs date -d @ ——--raw 可能多输出换行，导致 xargs 失败
• 稳妥做法是加超时和错误处理：timeout 2 redis-cli -h 127.0.0.1 -p 6379 LASTSAVE 2>/dev/null | xargs -r date -d @ 2>/dev/null

rdb_last_save_time 返回 0 怎么办

返回 0 不代表出错，只说明 Redis 启动后从未成功生成过 RDB 文件。常见原因有：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 实例刚启动，还没触发任何自动保存（比如配置了 save 900 1，但 900 秒内没发生 1 次写入）
• 手动执行过 SAVE 或 BGSAVE 但失败了（rdb_last_bgsave_status 会是 err），而失败不会更新 rdb_last_save_time
• AOF 已启用（aof_enabled:1）且没配 save 规则，RDB 自动触发被关闭
• 磁盘满、fork 失败、权限不足等底层问题，需查 redis.log

为什么 rdb_last_save_time 和 dump.rdb 文件修改时间对不上

这是正常现象，因为 RDB 写入是两阶段原子操作：

• 子进程先写临时文件（如 temp-12345.rdb）
• 写完再用 rename(2) 原子替换为 dump.rdb
• rdb_last_save_time 在 rename 前一刻更新，所以文件 mtime 通常比它晚 1–3 秒
• 如果发现文件 mtime 比 rdb_last_save_time 早很多（比如早几小时），大概率是人工拷贝/覆盖了 dump.rdb，Redis 完全不知情

监控时容易忽略的关键点

光看 rdb_last_save_time 数值是否“太久”是危险的。必须联动判断：

• 先确认是否还在自动触发：用 redis-cli CONFIG GET save 看有没有生效的规则（空值或全注释 = 不会自动 RDB）
• 再确认当前没卡住：redis-cli INFO persistence | grep rdb_bgsave_in_progress，值为 1 表示正在 fork + 写盘，此时 rdb_last_save_time 不会更新
• 最后才比时间差：比如配置了 save 300 10，但距今已超 600 秒还没更新，就得告警——不是时间戳本身有问题，而是持久化机制可能失效了