缓存有效期应动态调整而非固定值：热资源延长TTL、冷资源缩短TTL；可通过Redis计数器、Nginx map分级、Prometheus闭环调控及LangChain会话活跃度分层实现。
缓存有效期不能只设一个固定值，尤其在流量波动大的场景下。真正有效的做法是让缓存时间随请求热度动态调整——访问越频繁、越“热”的资源，缓存时间越长；冷资源则快速过期，释放内存并保证内容新鲜度。
用 Redis + 访问计数实现热度感知
核心思路是把缓存键和它的访问频次绑定管理：
- 每次读取缓存时，同时执行 INCR key:count 和 EXPIRE key:count 3600（给计数器设1小时过期）
- 根据计数器值决定主缓存的 TTL：比如 count ≥ 100 → TTL 设为 7200 秒；count ≥ 10 → TTL 设为 1800 秒；否则设为 300 秒
- 写入缓存时调用 SETEX key ttl value，确保每次更新都带新有效期
结合 Nginx 的 $request_uri 与 map 动态分级
在反向代理层做轻量级热度响应，适合静态资源或 API 路径：
- 用 map 指令将 URI 分类，例如 /api/v1/reports/.* → “hot”，/api/v1/user/profile → “warm”，其余 → “cold”
- 再用 limit_req_zone $uri zone=hotzone:10m rate=10r/s 等方式间接反映热度，并配合 proxy_cache_valid 分级设置：
- proxy_cache_valid 200 302 hot 1h;
- proxy_cache_valid 200 302 warm 10m;
- proxy_cache_valid 200 302 cold 1m;
利用 Prometheus + 自定义指标自动调节
对关键业务接口，可接入监控系统做闭环控制：
- 采集每分钟请求数（QPS）、缓存命中率、后端响应延迟等指标
- 用 PromQL 写规则，如：rate(http_requests_total{job="api"}[5m]) > 50 触发“高热”信号
- 通过脚本调用配置中心 API 或直接 reload Nginx，动态更新 proxy_cache_valid 或 Redis 中的 TTL 策略
LangChain / LLM 场景下的上下文热度缓存
用户会话不是均匀分布的，可按活跃度分层：
- 刚发起对话的 session ID，TTL 设为 5 分钟（防误触/测试流量）
- 30 分钟内有 ≥3 次请求的 session，TTL 自动延长至 2 小时
- Redis 中用 GETEX session:xxx EXAT [unixtime] 实现带时间戳的精准续期
- 搭配 redis-py 的 pipeline 批量操作，避免多次往返影响延迟
