缓存为啥会“过期”？
打开手机App，刷到的新闻列表飞快加载，不用等。这背后八成是缓存的功劳。可你有没有遇到过，刚改完资料，页面刷新还是旧内容？多半是缓存没及时失效。
缓存不是设了就完事，关键是怎么让它在该走的时候走——也就是“缓存失效策略”。用得好，系统又快又准；用不好，用户看到的就是“昨天的天气预报”。
定时过期：最简单的办法
比如商品详情页，价格不会每秒变，那就缓存10分钟。到期自动删掉，下次请求再从数据库拿新数据。
redis.setex("product:1001", 600, json_data) # 缓存10分钟这就像家里的牛奶，保质期7天，过了就扔。简单直接，适合变化不频繁的数据。
主动删除：一更新就动手
用户改了头像，总不能让人等10分钟才看到新照片吧？这时候就得主动出击。
一旦数据库更新，立刻把对应的缓存删掉。下一次请求发现缓存没了，自动回源取新数据，再重建缓存。
# 更新数据库
update_user_avatar(user_id, new_url)
# 立刻清除缓存
redis.delete("user:profile:" + str(user_id))这就像衣服脏了立马脱下来洗，不等到周末统一处理。
延迟双删：防“脏读”的小心机
有时候数据更新太快，刚删缓存，另一个线程马上读到旧数据写回去，等于白删。这种情况可以用“延迟双删”。
步骤是：先删一次缓存 → 更新数据库 → 睡个几毫秒 → 再删一次缓存。确保中间没有机会把旧数据刷回来。
redis.delete("order:12345")
db.update_order_status(order_id, 'shipped')
time.sleep(0.01) # 延迟10ms
redis.delete("order:12345")虽然有点“暴力”，但在订单状态这种敏感场景里，宁可多删一次，也不能让用户看到错的。
加版本号：让旧缓存自己失效
有些数据不想频繁删，但又要保证更新后能用上。可以给缓存加个版本号。
比如首页配置信息，每次更新就加一。客户端请求时带上当前版本，如果对不上，就重新拉。
# 缓存key包含版本
key = f"home:config:v{current_version}"
redis.set(key, config_data, ex=3600)这就像软件更新，你装的是v1.2，服务器已经是v1.3，自然要提醒你升级。
实际场景怎么选？
电商商品页，价格变动少，用定时过期完全够用。用户中心这种高频个性化内容，必须主动删除。金融交易记录？建议延迟双删+日志补偿，万无一失。
没有“最好”的策略，只有“最合适”的组合。关键是理解业务节奏——数据多久变一次？用户能不能容忍短暂不一致？
别忘了兜底方案
缓存崩了怎么办？设置最大过期时间（TTL），哪怕忘了删，顶多撑一天。再配个监控，发现缓存命中率暴跌，立马报警。
就跟家里装烟雾报警器一样，不怕一万，就怕万一。