17370845950

Python接口缓存需按场景选策略：本地缓存适用于高频读低更新场景，Redis适合多实例共享，HTTP缓存用于静态响应；须精准设计缓存键、防范穿透雪崩击穿，并加强可观测性与降级能力。

Python接口缓存不是“加个装饰器就完事”，关键在选对策略、控好粒度、避开陷阱。缓存用得好，QPS翻倍、数据库压力骤降；用得莽撞，数据不一致、内存爆满、雪崩连环发生。

按场景选缓存层级：本地、分布式、响应级

不同接口对一致性、吞吐、延迟要求差异大，缓存不能一刀切：

• 高频读+低更新频率（如配置项、城市列表）：优先用 functools.lru_cache 或 cacheout 做进程内缓存，毫秒级响应，零网络开销
• 多实例共享+强一致性容忍短时延迟（如用户资料、商品详情）：上 Redis，配合 TTL + 主动失效（如更新商品时删对应 key），避免各节点缓存不一致
• 纯静态响应（HTML 页面、JSON API 返回体固定）：在 Web 框架层做 HTTP 缓存（Cache-Control、ETag），让 CDN 或客户端直取，请求甚至不进 Python 进程

精准控制缓存键：别让“user_id=1”和“user_id=1&lang=zh”混成一个

缓存键（cache key）设计错误是脏数据的头号推手。常见问题：

• 忽略查询参数、请求头（如 Accept-Language、Authorization 中的 tenant_id）
• 把整个 request.args 当字典哈希——但字典键顺序不确定，导致同一请求生成不同 key
• 未标准化输入："id=123" 和 "id=0123" 应视为相同，但字符串直接拼接会缓存两份

建议做法：对关键参数排序后拼接成规范字符串，例如：
f"get_user:{sorted_dict_hash({'id': user_id, 'lang': lang})}"

防穿透、防雪崩、防击穿：三道防线必须有

真实线上环境，缓存不是稳态，而是动态战场：

• 穿透：查不存在的 id（如 -1、超长随机串），大量打穿缓存直击 DB → 用布隆过滤器预判“key 是否可能有效”，或对空结果也缓存短时间（如 60s）
• 雪崩：大量 key 同一时刻过期，DB 瞬间被压垮 → 给 TTL 加随机偏移（如 300 + random.randint(0, 60)）
• 击穿：热点 key 过期瞬间，多个并发请求同时重建 → 用 Redis 的 SETNX + 过期时间实现“逻辑锁”，只放行一个请求回源加载，其余等待或短暂重试

可观测与可降级：缓存不是黑盒

上线后必须能看清缓存是否生效、命中率多少、哪些 key 占内存最多：

• 在关键装饰器里埋点：记录 hit/miss、耗时、key 长度、value 大小（避免缓存超大对象）
• 暴露 Prometheus 指标，比如 cache_hit_total{endpoint="user/profile"}
• 预留开关：通过配置中心动态关闭某接口缓存（如发现数据异常时快速止损）

不复杂但容易忽略。