Python异步缓存技巧：async-lru加速接口响应

本文深入解析了Python异步开发中关键的缓存利器async-lru——它虽能无缝装饰async def函数大幅提升响应速度（平均延迟仅0.1ms），却暗藏三大易踩陷阱：必须严格使用带括号的@alru_cache()调用形式、缓存键仅支持可哈希参数（需手动转换headers为frozenset等）、且完全不支持TTL自动过期；更需警惕其进程内内存缓存的本质——无跨实例共享能力、重启即失、无法替代Redis等分布式方案，尤其在HTTP请求封装、类方法缓存、缓存清理与命中监控等实战场景中，稍有不慎便导致缓存失效、崩溃或数据陈旧，是异步服务性能优化前不可忽视的底层细节。

async-lru 能否直接装饰 async def 函数

能，但必须用 @alru_cache()（注意末尾括号），不是 @alru_cache。漏掉括号会导致装饰器未被调用，函数仍无缓存行为，且不会报错——这是最常踩的坑。

它只支持 Python 3.7+，且要求被装饰函数返回协程对象（即 await 后能拿到结果），不支持直接缓存 async for 或流式响应。

• alru_cache() 是异步版 functools.lru_cache()，底层用 asyncio.Lock 保证并发安全
• 缓存键基于位置参数和关键字参数的值生成，self 或 cls 不参与计算（所以类方法需谨慎）
• 不支持对 **kwargs 中不可哈希类型（如 dict、list）做缓存，会抛 TypeError: unhashable type

如何缓存带 session 或 headers 的 HTTP 请求

不能直接缓存 aiohttp.ClientSession.get() 这类底层调用，因为 ClientSession 实例本身不可哈希；必须封装成纯函数，把 URL、headers、params 等可哈希参数显式传入。

典型错误是把 session 当作参数传进 @alru_cache() 装饰的函数——这会让缓存失效或崩溃。

• 正确做法：提取请求逻辑为独立 async 函数，参数仅含 url、timeout、headers（且 headers 用 frozenset(headers.items()) 转为可哈希类型）
• 避免传入 session，改由函数内部从全局或上下文获取已复用的 ClientSession
• 若需区分用户身份缓存，把 user_id 或 token_hash 作为参数传入，而非从 request 对象动态读取（那会破坏缓存一致性）

缓存失效与手动清除怎么做

async-lru 没有内置 TTL 或自动过期机制，所有缓存项永久存在，直到内存溢出或手动清理——这点和 Redis 缓存完全不同，容易误判为“缓存没生效”或“数据陈旧”。

清除方式只有两种：重置整个缓存，或按签名精准删除。

• 清空全部：your_func.cache_clear()
• 删指定调用：await your_func.cache_remove(arg1, arg2, key="value")（需确保参数完全一致）
• 查看命中率：your_func.cache_info() 返回 CacheInfo(hits=12, misses=3, maxsize=128, currsize=5)
• 不支持基于时间/条件的自动失效，如有此需求，得自己套一层包装逻辑（例如在函数开头检查时间戳）

和 Redis 异步缓存比有什么实际差异

本质区别在于作用域：async-lru 是进程内内存缓存，快但不共享；Redis 是跨进程/跨服务的外部缓存，慢一点但一致性强。

本地缓存适合高频读、低更新、容忍短暂不一致的场景（如配置查询、静态元数据）；一旦涉及多实例部署或强一致性要求（如库存、订单状态），单靠 async-lru 无法解决。

• async-lru 平均读取延迟 ≈ 0.1ms，Redis（同机房）≈ 1–5ms
• 重启进程后 async-lru 全丢，Redis 持久化后可恢复
• 无法用 async-lru 实现“一个写、多个读”的缓存穿透防护，得配合分布式锁或二级缓存方案

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~