异步刷新缓存的核心逻辑是命中逻辑过期数据时先返回旧值，再后台异步查库更新缓存，通过expireAt字段判断过期而非Redis物理TTL，并用分布式锁保障并发安全。
异步刷新缓存的核心逻辑是什么
异步刷新不是“不查数据库”，而是把“查库 + 写缓存”这个耗时操作从主请求链路里剥离开。用户请求命中缓存后，即使数据已逻辑过期，也先返回旧值，同时后台悄悄去更新——这样既避免了大量请求同时击穿到 DB，又不会让前端感知延迟。
关键在于区分「物理过期」和「逻辑过期」：setex 是物理过期（key 真没了），而异步刷新依赖的是数据体里自带的 expireAt 字段，Redis 本身不删它，靠业务代码判断是否该更新。
用 redis-py 实现逻辑过期 + 异步更新（Python）
常见错误是直接在 get 后启动 threading.Thread，但 Python 的 GIL 和短生命周期线程容易导致更新丢失；更稳妥的是交给线程池或任务队列。
- 读取时先
redis.get(key)，反序列化后检查data['expireAt'] < time.time() - 若已逻辑过期，调用
executor.submit(update_cache_async, key)（别用run_in_executor嵌套太多层） -
update_cache_async要加分布式锁（如redis.set(lock_key, 1, nx=True, ex=5)），否则并发更新会写乱 - 更新成功后，新数据必须带新的
expireAt字段，并用redis.set(key, json.dumps(new_data))（不设 TTL）
def update_cache_async(key):
lock_key = f"lock:refresh:{key}"
if redis.set(lock_key, "1", nx=True, ex=5):
try:
fresh_data = db.query(key)
fresh_data["expireAt"] = int(time.time()) + 3600
redis.set(key, json.dumps(fresh_data))
finally:
redis.delete(lock_key)
为什么不能只靠 EXPIRE 配合后台定时任务
定时任务刷新看似简单，但存在两个硬伤：一是无法响应突发热点（比如某商品突然爆火，定时任务还没轮到就已雪崩）；二是更新窗口和业务读取节奏错位，可能刚刷完就过期，或者长时间不刷导致全量失效。
- 定时任务适合低频、可预测的数据（如城市列表），不适合用户行为驱动的热点（如热搜榜、购物车）
- 异步刷新是“按需触发”，谁读到过期数据，谁就触发一次后台更新，天然适配流量分布
- 注意线程池大小：一般设为 DB 连接池的 1/2～1/3，避免新建连接打满数据库
容易被忽略的边界问题
异步刷新最常翻车的地方不在主逻辑，而在兜底和可观测性。
- 更新失败不能静默：要记录日志 + 上报监控（如 Prometheus 的
cache_refresh_failed_totalcounter） - 锁续期没做：如果
update_cache_async执行超 5 秒，锁自动释放，可能被另一个请求重复抢占 → 改用 Redisson 的可重入锁或带 heartbeat 的锁 - 本地缓存未同步：如果用了 Caffeine 等本地缓存，异步更新 Redis 后，本地副本仍是旧的 → 需配合事件总线或主动失效本地 key
- 首次加载没异步化：服务刚启动时，所有 key 都是空的，这时第一个请求必须同步加载，否则全量击穿 → 启动时预热 + 首次访问降级为同步
真正难的不是写个 submit，而是让异步动作可追踪、可重试、不干扰主流程。上线前得压测验证：当 1000 QPS 持续打一个逻辑过期 key，DB 查询峰值是否稳定在 1～2 次/秒，而不是瞬间飙到几百。
