17370845950

缓存需权衡数据不变性、访问频率、内存开销与一致性；只缓存计算昂贵、

读多写少、生命周期可控的数据，如纯函数结果、带TTL的外部API响应、低频更新的维度表；禁用动态值、毫秒级计算及大对象；选对工具并设过期与失效机制，监控命中率与存留时间，配置降级策略。

缓存不是“加了就快”，而是要在数据不变性、访问频率、内存开销和一致性之间做权衡。合理使用的关键是：只缓存那些计算昂贵、读多写少、生命周期可控的数据。

明确缓存边界：什么该缓存，什么不该

适合缓存的典型场景：

• 纯函数结果（输入相同，输出恒定），比如解析固定配置文件、生成静态 HTML 模板
• 外部 API 的响应（需配合 TTL 和错误降级，避免缓存失败响应）
• 数据库查询结果（仅限低频更新的维度表、状态枚举等，严禁缓存用户订单这类强实时数据）

明确不建议缓存的：

• 含当前时间、随机数、用户会话 ID 等动态上下文的返回值
• 单次调用耗时低于 1ms 的本地计算（缓存本身开销可能更高）
• 大小超过几 MB 的对象（易引发内存压力或 GC 颠簸）

选对工具：内置装饰器 vs 手动管理

@lru_cache 适合简单、无副作用、参数可哈希的函数：

✅ 正确用法：def get_user_role(user_id: int) -> str: ...（user_id 是整数，角色极少变更）
❌ 错误用法：def process_request(data: dict) -> dict: ...（dict 不可哈希，会报错；且 request 数据高度动态）

需要精细控制时，用 functools.cached_property（实例属性级缓存）或第三方库如 diskcache（支持持久化、淘汰策略、线程安全）。

必须设置过期与失效机制

无过期的缓存等于埋雷。Python 标准库不提供带 TTL 的 LRU，需自行补充：

• 用 cache = TTLCache(maxsize=128, ttl=300)（来自 cashews 或 aiocache）
• 手动在 @lru_cache 外包一层时间检查（适合简单场景）
• 写操作后主动 cache_clear() 或按 key 删除（如更新用户信息后删掉对应 get_user(id) 缓存）

特别注意：分布式环境下，单机缓存清除无效，需结合 Redis 的 publish/subscribe 或删除共享缓存。

监控与降级：缓存不是黑盒

上线后要可观测：

• 记录缓存命中率（命中数 / 总请求数），持续低于 70% 要重新评估是否值得缓存
• 统计缓存平均存留时间，过短说明更新太频繁，缓存收益低
• 设置 fallback：当缓存不可用（如 Redis 连接失败），自动回退到原始逻辑，而非直接报错

可用 tenacity 重试 + structlog 打点，把缓存行为变成可追踪的日志事件。