本文介绍在存在写操作和数据截断（truncate）等破坏性操作的场景下，为读取方法设计安全、一致的缓存策略，重点解决因缓存未失效导致的脏读问题。
在时间序列数据管理中，按日粒度读写（如 read(for_date) / write(for_date, data)）是常见模式。虽然 @lru_cache 能显著提升重复读取性能，但其默认行为不感知外部状态变更——一旦 truncate() 删除了某日期的数据，后续对同一 for_date 的 read() 若命中缓存，将返回已不存在的陈旧数据，造成逻辑错误。
最直接且鲁棒的解决方案是：将缓存生命周期与数据生命周期严格对齐。具体实现如下：
from functools import lru_cache, wraps
class DataManager:
def __init__(self):
# 将 read 方法缓存化，并暴露 cache_clear 接口
self._read_cached = lru_cache(maxsize=128)(self._read_uncached)
def _read_uncached(self, for_date):
# 实际 DB 查询逻辑（例如：SELECT * FROM table WHERE date = ?）
return self._execute_sql_query("SELECT * FROM data_table WHERE date = ?", for_date)
def read(self, for_date):
return self._read_cached(for_date)
def write(self, for_date, data):
# 执行写入
self._execute_sql_query("INSERT OR REPLACE INTO data_table (date, value) VALUES (?, ?)", for_date, data)
# 写入后主动刷新该日期缓存（可选：提高后续读取一致性）
self._read_cached.cache_clear() # 或更精细地：self._read_cached.cache_remove(for_date)（需自定义）
def truncate(self, cutoff_date, inclusive=True):
# 先执行数据库截断
where_clause = "date > ?" if not inclusive else "date >= ?"
self._execute_sql_query(f"DELETE FROM data_table WHERE {where_clause}", cutoff_date)
# 关键：同步清空整个缓存（因无法精确预知哪些日期被影响）
self._read_cached.cache_clear()
def _execute_sql_query(self, sql, *params):
# 此处封装实际数据库调用（如 sqlite3.execute / SQLAlchemy session.execute）
pass✅ 为什么 cache_clear() 是首选？
- 简单可靠：truncate() 影响的是一个日期范围（>= cutoff_date），而非单个键，无法高效枚举所有待驱逐的缓存键；
- 成本可控：lru_cache.cache_clear() 是 O(1) 操作，远低于潜在的脏读风险；
- 符合直觉：数据批量删除 → 缓存批量失效，语义一致。
⚠️ 注意事项与进阶建议：
- 若 truncate() 极少调用而 read() 频繁，cache_clear() 的代价可接受；若需更高精度，可维护一个轻量级“已截断日期范围”元数据，读取前动态检查（但会增加读路径复杂度，通常不必要）；
- 避免在 write() 中仅清除单个键（如 cache_remove(for_date)）：因并发或事务隔离问题，其他线程可能已写入但未提交，此时局部清理仍可能导致不一致；
- 对于分布式环境，需升级为外部缓存（如 Redis）并配合发布/订阅机制通知缓存失效，但本例单进程下 lru_cache + cache_clear() 已足够健壮。
总结：缓存不是银弹，而是需要与业务语义协同的设计决策。 在存在显式破坏性操作（如 truncate）的场景中，“写即清”（write-through cache invalidation）比“写即更新”（write-through cache update）更安全、更易验证。
