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返回的是缓存对象的引用，修改缓存对象会直接改变缓存中的数据。以下代码模拟了该问题：

立即学习“”；

from functools import lru_cache import time import typing as t from copy import deepcopy  @lru_cache def 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, wraps from copy import deepcopy  def 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 缓存可变值的详细内容，更多请关注php中文网其它相关文章！