Python怎么实现带过期的内存缓存_结合dict与time实现TTL逻辑

不能直接用普通 dict 做带过期的缓存，因为 dict 不记录写入时间、无法自动清理过期项，每次读取需手动校验时间且遍历删除性能差、易漏删、线程不安全。

为什么不能直接用普通 dict 做带过期的缓存

直接拿 dict 当缓存，最大的问题就是它“没记性”——写入时不会记录时间戳，读取时也不会自动判断是否过期。你查 cache['key']，它只会傻乎乎地返回值，根本不管这个值是不是已经“超时下线”。就算你自己在存的时候偷偷记个时间，每次读都得手动跟 time.time() 比一比，过期了还得遍历删，效率低、容易漏、还线程不安全。说白了，dict 就不是为缓存设计的。

最简可行方案：封装一个 TTLCache 类，用 time.time() + dict 维护

核心思路其实很简单：每个 key 存一个元组 (value, expire_at)，expire_at 是过期的时间戳。读取时检查 expire_at < time.time()，没过期就返回值，过期了就删掉并返回 None。写入时直接算好绝对时间戳，而不是存相对秒数——这样更稳定，系统时间跳变或 NTP 同步时不会乱套。

• 写入时用 time.time() + ttl_seconds 存绝对时间戳，比存相对时间更靠谱（尤其在系统时钟步进时）
• 读取时不做删除动作，只判断是否过期；真正清理交给 get() 或 __getitem__() 中的惰性剔除
• 如果需要批量清理，可以加个 purge() 方法遍历删，但别在每次 get 里全量扫——O(n) 太伤

import time

class TTLCache:
    def __init__(self):
        self._data = {}

    def set(self, key, value, ttl):
        self._data[key] = (value, time.time() + ttl)

    def get(self, key, default=None):
        item = self._data.get(key)
        if item is None:
            return default
        value, expire_at = item
        if time.time() > expire_at:
            del self._data[key]
            return default
        return value

    def __contains__(self, key):
        return self.get(key) is not None

time.time() 精度和时钟漂移会影响 TTL 准确性吗

确实会，但大多数场景下可以接受。Linux/macOS 上 time.time() 默认基于 CLOCK_REALTIME，精度约毫秒级，而且受系统时钟调整影响——比如 NTP 的 step 调整会导致时间突变。如果业务对“严格±100ms 内过期”有强要求，那就得换 time.monotonic()。它不随系统时间跳变，但无法映射到真实时间点，所以必须在 set() 时记录起始单调时间，并基于 ttl 做相对偏移。

• 用 time.monotonic() 的话，set() 存的是 (value, time.monotonic() + ttl)，get() 比较用 time.monotonic() > expire_at
• 缺点：无法实现“固定时刻过期”，比如“每天凌晨 2 点清空”，只能做“写入后 N 秒过期”
• 优点：完全免疫系统时钟倒拨/跳跃，TTL 行为可预测

并发访问下 dict 不是线程安全的，怎么办

dict 的读写在 CPython 中虽有 GIL 保护，但像 if key in d: return d[key] 这种“检查-读取”操作不是原子的，多线程下可能读到过期值或触发 KeyError。真要在线程间共享，必须加锁。

• 最简单是给整个 _data 加 threading.RLock()，所有方法入口加 with self._lock:
• 不要用 @synchronized 或装饰器隐藏锁逻辑——容易漏锁，也难调试
• 如果用在 asyncio 环境，换成 asyncio.Lock()，但注意：不能混用同步/异步锁
• 高并发场景下，锁粒度太粗会成瓶颈，这时该考虑 functools.lru_cache + 外部 TTL 轮询，或直接上 redis

实际用的时候，多数小项目够用；但一旦缓存键量级上万、或要求强一致性、或部署在容器里频繁启停，就别硬撑——TTL 逻辑会迅速变得脆弱。时间戳怎么存、锁怎么加、过期怎么测，每个细节松一扣，线上就容易出“缓存雪崩”或“脏读”。