rdb_last_save_time是Redis中唯一标识上一次RDB持久化成功完成时间的Unix时间戳字段，需用date -d @<timestamp>（Linux）或date -r <timestamp>（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 秒还没更新，就得告警——不是时间戳本身有问题，而是持久化机制可能失效了
