Redis EXPIRETIME 怎么核对绝对过期时间：秒级时间戳、时钟偏差与恢复检查

缓存明明设置了 30 分钟，业务日志里却显示还有 29 分钟，重启 Redis 后又有人说过期时间“变了”。这类问题通常不是 Redis 把时间改乱了，而是把剩余时间、绝对时间戳和应用机器自己的时钟混在了一起。EXPIRETIME 用秒级 Unix 时间戳告诉你一个键计划在哪一刻过期，配合 TTL、TIME 和毫秒版 PEXPIRETIME，可以把这条链路核对清楚。

EXPIRETIME 和 TTL 看的不是同一种时间

TTL 回答的是“现在还剩多少秒”，EXPIRETIME 回答的是“按 Redis 当前时钟，哪一个 Unix 时间戳会过期”。例如先写一个 30 秒的键：

SET cache:session:42 ready
EXPIRE cache:session:42 30
TTL cache:session:42
EXPIRETIME cache:session:42

前一条读取可能得到 29，后一条得到类似 1787585465。两者相差一两秒是读取耗时和整数取整造成的正常现象；真正需要警惕的是时间单位错位或绝对时间明显落在过去。

先把三种返回值分开记录

排查时不要只把命令结果打印成一句“过期时间异常”。至少记录键名、TTL、EXPIRETIME 和 Redis 的 TIME。状态码式的两个负数尤其重要：

EXPIRETIME cache:missing
(integer) -2

SET cache:permanent ready
EXPIRETIME cache:permanent
(integer) -1

-2 表示键不存在，可能是已经过期，也可能是从未写入；-1 表示键存在但没有关联过期时间。若监控把这两个值统一显示为“永久”，会掩盖缓存击穿前的删除问题。

在 Redis CLI 中还可以直接查询服务器本地时间：

TIME
EXPIRETIME cache:session:42

把 TIME 的秒部分与 EXPIRETIME 相减，结果应该接近 TTL。差值随着命令执行自然减少，不要求每次恰好相等。

秒和毫秒混用，是最容易误判的输入风险

EXPIREAT 接受秒级 Unix 时间戳，PEXPIREAT 接受毫秒级时间戳。写入端如果把 JavaScript 的 Date.now() 结果直接传给秒级命令，时间会被推到非常遥远的未来；反过来把秒值传给毫秒命令，键可能立即失效。

# 秒级绝对时间
EXPIREAT cache:report 1787586000
EXPIRETIME cache:report

# 毫秒级绝对时间
PEXPIREAT cache:report:ms 1787586000123
PEXPIRETIME cache:report:ms

验收时先核对写入命令和客户端序列化逻辑，再比对返回值的数量级。不要仅凭返回值是正数就认定过期设置生效，还要确认数值落在业务允许的时间窗口范围内。

遇到时钟偏差，先以 Redis TIME 为参照

应用日志使用的是应用主机时钟，EXPIRETIME 使用的是 Redis 的时间基准。容器节点、虚拟机和宿主机之间若没有正确同步，日志里看起来就会提前或延后。检查顺序建议固定为：

1. 在同一连接读取 TIME 与目标键的 EXPIRETIME。
2. 将两者相减，确认剩余量是否和 TTL 同方向变化。
3. 再对比应用节点的 UTC 时间和日志采集时间，不要直接拿本地时区字符串做差值计算。
4. 如果 Redis 发生重启或者主从切换，要重新读取目标键的状态，不要沿用切换前应用本地缓存的旧时间数据。

Redis 官方的 key 过期说明指出，过期信息会参与复制和持久化，停机期间时间仍会继续推进。恢复后应以当前实例实际返回的 TTL 与绝对时间为准，不能用“重启后剩余时间应该冻结”的假设验收。

把核对结果写进发布和审计清单

如果操作的是登录会话、短期授权或者防重复提交类的键，建议把下面几项作为每次变更的固定校验记录：

• 写入命令是 EXPIRE、EXPIREAT、PEXPIRE 还是 PEXPIREAT。
• 输入时间的单位，以及客户端是否做了显式的秒/毫秒转换处理。
• Redis TIME、TTL、EXPIRETIME 的同一时刻采样值。
• 主从切换或者故障恢复后，目标键是否仍然存在、是否保留了原有过期属性。
• 监控是否把 -1 和 -2 分开告警。

这样记录可以清晰区分「键已被删除」「键未设置过期时间」「应用本地时钟异常」「写入单位参数错误」四类常见问题，后续排查不需要靠推测定位。

常见问题

EXPIRETIME 返回的是剩余秒数吗？

不是。它返回秒级 Unix 绝对过期时间；剩余秒数应读取 TTL。

为什么 EXPIRETIME 会返回 -1？

目标键存在，但没有配置过期时间。这个返回结果不代表键马上过期，要检查写入流程是不是漏掉了过期参数设置。

EXPIRETIME 和 PEXPIRETIME 该怎么选？

秒级策略使用 EXPIRETIME；当写入端使用 PEXPIREAT 或需要毫秒精度时，配套使用 PEXPIRETIME。

Redis 重启后 EXPIRETIME 会重新计算吗？

不要用应用缓存的旧值推断状态。实例恢复后直接读取当前节点的实时数据；持久化和主从复制都会完整保留过期语义，不过剩余过期时间会顺着真实系统时间正常推进。

用绝对时间戳把过期问题落到证据上

TTL 适合看倒计时，EXPIRETIME 适合看最终时刻，TIME 负责提供 Redis 自己的时间参照。把三者与写入命令、时间单位和恢复后的实际键状态放在同一份记录里，秒毫秒混用和时钟偏差就会从“感觉不对”变成可以复核的证据。