真正防垃圾的关键是让过期逻辑不依赖本地时钟，否则手动调时、NTP偏差或虚拟机暂停会导致缓存“假过期”或“永不过期”；应优先用单调时钟（如Python的time.monotonic()、Java的System.nanoTime()）、服务端授时锚点、存储层原生TTL（如Redis的SETEX），并配以运行时时间漂移检测与可观测性监控。
靠系统时间驱动的自定义 TTL 容易失效，真正防垃圾的关键是让过期逻辑不依赖本地时钟——否则一次手动调时、NTP 同步偏差或虚拟机暂停，就可能让大量缓存“假过期”或“永不过期”，最终堆满无效数据。
别把过期判断交给 system time
很多自研缓存（比如用字典 + time.time() 实现的 TTLCache）直接拿当前时间戳比对过期时间。一旦服务器时间被回拨 5 分钟，所有本该还剩 3 分钟的缓存立刻判定为过期；若被快进 1 小时，则整批数据延迟失效——内存里全是陈旧副本。这不是设计缺陷，而是原理性风险。
- Python 中优先用 time.monotonic() 记录相对存活时长，它不随系统时间调整跳变
- Java 对应 System.nanoTime()，适合计算“已存在多久”，但不能单独用于绝对过期
- 如果必须支持绝对过期（如“每天凌晨 2 点清空”），需配合服务端授时锚点，而非信任本地 clock
把过期责任交给存储层本身
Redis、Memcached、Cassandra 这类专业存储都内置了抗时间篡改的 TTL 引擎。它们用自身单调时钟管理过期，客户端只管设值，不参与判断——这才是最省心也最可靠的方式。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- Redis 用 SETEX key 3600 value 或 SET key value EX 3600，过期由 Redis server 内部完成
- Cassandra 在 INSERT/UPDATE 时加 USING TTL 3600，过期标记和清理由协调节点与压缩流程保障
- 避免在应用层反复读取再判断：比如先 GET 再比对时间戳再 DEL，这既慢又容易漏判
给每类数据配合理的生存周期
TTL 不是越大越好，也不是越小越安全。过长会导致数据陈旧，过短则击穿数据库、放大延迟。关键看数据变化频率和业务容忍度。
- 用户会话：5–30 分钟，登出时主动 DEL，避免残留
- 商品详情页：1–4 小时，库存变更后同步 DEL product:1001
- 排行榜/聚合统计：30 分钟–1 小时，配合定时任务刷新并重置 TTL
- 配置类数据：可设为 24 小时，但建议增加版本号或 MD5 校验，变化时强制更新 key
加一层运行时防护和可观测性
即使用了存储层 TTL，也要防止机器时间漂移悄悄破坏逻辑。上线前和运行中都要主动检测。
- 启动时执行 ntpq -p（Linux）或 w32tm /query /status（Windows），offset 超 ±500ms 则拒绝加载缓存模块
- 监控 Redis 的 expired_keys 指标，持续低于新增 key 速率，说明过期没生效
- 记录缓存 miss 日志，若出现“批量 key 在同一秒集中未命中”，大概率是时间被统一调快导致集体过期
