Python缓存协议选择指南

Python的缓存机制选择本质是权衡：@lru_cache轻量高效但仅限单进程、无过期、键需可哈希，适合配置解析等内部高频调用；一旦涉及多进程、跨机器、TTL控制或强一致性需求（如Web接口、会话管理），就必须转向Redis等外部缓存——虽引入网络延迟，却换来数据统一与灵活失效能力；而cached_property则专注实例级惰性计算，安全简洁却不可复用；高可用场景下，真正考验架构功力的不是缓存协议本身，而是如何通过本地+分布式组合、随机TTL、降级兜底与轻量锁协同，优雅应对缓存失效瞬间的“旧数据”与“服务降级”挑战。

Python 中 @lru_cache 为什么不能跨进程共享缓存

因为 @lru_cache 是纯内存实现，每个 Python 进程启动时都有一份独立的缓存字典，父子进程 fork 后虽然初始内容相同，但后续写入互不影响。多进程场景下（比如用 multiprocessing 或 Gunicorn 多 worker），你看到的“缓存命中”只是单个进程内的假象。

常见错误现象：time.sleep(2) 的函数加了 @lru_cache，开两个终端分别调用，各自都要等 2 秒——说明缓存没穿透到对方进程。

• 只适合单线程/单进程内高频重复调用，比如解析固定配置、递归斐波那契
• 缓存键基于 args 和 kwargs 的 hash()，含不可哈希对象（如 dict、list）直接抛 TypeError: unhashable type
• 不支持 TTL（过期时间），清空只能靠 func.cache_clear() 或重启进程

什么时候该换 redis 或 memcached 做缓存

当你需要跨进程、跨机器、带过期、可主动失效的缓存时，@lru_cache 就该让位了。典型场景：Web 接口查数据库结果、用户会话状态、API 频率限制计数器。

性能与兼容性影响：网络 IO 成为瓶颈，单次缓存读取从纳秒级升到毫秒级；但换来的是强一致性基础——所有服务实例看到同一份数据。

• redis-py 的 client.get(key) 返回 bytes，记得用 .decode() 或设 decode_responses=True
• 避免把大对象（如整个 Pandas DataFrame）直接 set 到 Redis，序列化/反序列化开销大，优先存 ID 再查库
• Redis 持久化策略（RDB/AOF）会影响故障恢复后的一致性，若要求强一致，需配合业务层双删或延迟双写

functools.cached_property 和手动实现的属性缓存有何区别

cached_property 把计算结果绑定到实例 __dict__，只在第一次访问时执行函数，之后直接返回值。它不是全局缓存，也不依赖外部存储，所以不存在一致性问题——每个对象自己管自己的缓存。

容易踩的坑是误以为它能跨实例复用，或者在多线程下没加锁就修改被缓存的属性值。

• 仅适用于实例方法，且必须是无参数（除了 self）的计算型属性
• 如果属性值可能被外部修改（比如 obj._data = new_val），缓存不会自动失效，得手动删 del obj._cache_attr
• Python __get__ 中的线程安全（CPython GIL 不能完全保证）

本地缓存 + 分布式缓存的组合策略怎么防击穿

单纯用 Redis 有网络延迟和连接失败风险；全用 @lru_cache 又无法同步。折中做法是“本地内存缓存兜底 + Redis 主源”，但必须处理好缓存击穿（热点 key 过期瞬间大量请求打到后端）。

关键不是选哪个协议，而是控制失效节奏和 fallback 行为。

• Redis key 设置随机 TTL（比如 base=60s ± 10s），避免大量 key 同时过期
• 本地缓存（如 LRUCache）不设 TTL，但每次从 Redis 读取成功后更新本地副本，Redis 失败时直接返回本地旧值（允许短暂 stale）
• 对极热 key，用 Redis 的 SETNX + 过期时间实现简单互斥锁，防止多个请求同时回源

真正麻烦的从来不是协议本身，而是缓存失效那一刻，你的代码有没有准备好接受“旧数据”或“降级响应”。

今天关于《Python缓存协议选择指南》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！