Python缓存陷阱：可变对象与lru_cache
为了提升处理速度，缓存机制被广泛应用于各种系统，从cpu级别到数据库前端。缓存失效策略是缓存系统中一个复杂且重要的议题。本文将探讨一个看似简单却困扰开发者1.5年的缓存问题，以及如何通过简单的策略有效规避。
背景：本文作者在构建一个基于sklearn的自定义ML框架时，为了加速频繁访问的数据源，引入了缓存层。最初使用lru_cache，但很快发现需要持久化缓存，因为大量数据是静态的且反复访问。考虑到成本和性能，最终选择了diskcache（一个基于SQLite的Python模块）。该框架在32个进程下，处理高达500MB的Pandas DataFrame时表现良好。 diskcache作为持久层，lru_cache作为内存层，共同构成了高效的缓存机制。
问题：在1.5年内，该框架主要用于训练大量小型模型。缓存用于存储Pandas DataFrame和其他只读对象。随着用户数量增加，一些用户开始报告随机错误结果。问题难以复现，直到发现问题的根源：部分用户出于习惯，直接修改了从缓存中获取的DataFrame对象（inplace=True）。这不仅改变了当前结果，还影响了缓存中的数据。
问题剖析：lru_cache返回的是缓存对象的引用，修改缓存对象会直接改变缓存中的数据。以下代码模拟了该问题：
立即学习“Python免费学习笔记（深入）”；
from functools import lru_cacheimport timeimport typing as tfrom copy import deepcopy@lru_cachedef expensive_func(keys: str, vals: t.any) -> dict: time.sleep(3) return dict(zip(keys, vals))def main(): e1 = expensive_func(('a', 'b', 'c'), (1, 2, 3)) print(e1) e2 = expensive_func(('a', 'b', 'c'), (1, 2, 3)) print(e2) e2['d'] = "amazing" print(e2) e3 = expensive_func(('a', 'b', 'c'), (1, 2, 3)) print(e3) if __name__ == "__main__": main()
运行上述代码，你会发现修改e2后，e3也包含了新增的键值对。
解决方案：由于无法控制下游用户的使用方式，作者采用了简单的解决方案：在返回缓存对象之前，创建其副本。这样，用户可以随意修改副本，而不会影响缓存中的原始数据。虽然这会导致数据冗余，但对于该应用场景来说，这是可接受的代价。
架构思考：作者总结道，没有绝对好坏的架构，只有权衡利弊的选择。架构设计是关于在已知条件下，做出最优决策，最小化潜在风险。
改进方案：作者通过一个自定义装饰器，包装lru_cache，在每次访问时返回缓存对象的深度拷贝：
from functools import lru_cache, wrapsfrom copy import deepcopydef custom_cache(func): cached_func = lru_cache(func) @wraps(func) def _wrapper(*args, **kwargs): return deepcopy(cached_func(*args, **kwargs)) return _wrapper
经验教训：
深入理解lru_cache的工作机制。考虑用户的使用习惯，尽可能在设计中避免潜在问题。权衡各种方案的优缺点，选择最适合当前场景的方案。
通过这个案例，我们学习到，即使看似简单的缓存问题，也可能隐藏着复杂的陷阱。 深入理解缓存机制，并结合实际应用场景进行权衡，才能构建高效且稳定的系统。
以上就是Python 缓存可变值的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1355792.html
微信扫一扫 
支付宝扫一扫 
