缓存为什么在电商里这么重要
打开淘宝或京东，搜索“连衣裙”，瞬间跳出几千条结果，图也清晰，价格、库存一目了然。这背后不全是数据库在扛，靠的是缓存。缓存就像家门口的小卖部，数据不用每次都跑大超市（数据库）去取，就近拿，快得多。
但问题来了：如果商品降价了，小卖部还挂着旧价，用户点进去发现不一致，信任就崩了。这就是缓存和数据库数据不一致的典型场景。怎么让缓存及时“过期”，就成了关键。
常见的缓存失效方式
最简单的办法是给缓存设个有效期，比如10分钟。时间一到自动失效，下次请求重新从数据库加载。这叫TTL（Time To Live）。写法像这样：
redis.setex("product:10086", 600, productData); // 600秒后自动删除这种方式简单粗暴，适合对一致性要求不高的场景，比如商品详情页的评论数。可要是正在搞秒杀，库存只有一件，缓存还显示“有货”，用户下单才发现没库存，体验直接拉垮。
主动失效：更新数据库时顺手清理缓存
更靠谱的做法是，一旦数据库改了，立刻把对应的缓存删掉。比如后台运营把商品价格从99调到69，代码里除了更新数据库，还得加一句：
redis.del("product:10086");下次用户访问，发现缓存没了，自然会从数据库读新数据，重新写进缓存。这种模式叫“Cache-Aside”，用得最多。
应对突发高并发：预热与延迟双删
大促前，运营会上架一堆爆款。如果等到用户访问才去查数据库、建缓存，瞬间高并发可能直接压垮数据库。所以得提前“预热”——把热门商品的数据先加载进缓存。
还有一种 tricky 的情况：你刚删了缓存，还没来得及更新数据库，这时一个读请求进来，发现缓存空，就去查数据库，把旧数据又写回缓存。等数据库更新完，缓存反而还是旧的。为防这个，有人用“延迟双删”：
// 更新前先删一次
redis.del("product:10086");
// 更新数据库
db.update(product);
// 睡1秒，让可能的并发读操作完成
Thread.sleep(1000);
// 再删一次，干掉可能被误载入的旧数据
redis.del("product:10086");虽然听着有点笨，但在高并发场景下确实管用。
电商里的实战组合拳
真实系统不会只用一种策略。首页 Banner 商品用预热 + 长TTL；商品库存这种敏感数据，用更新即删缓存 + 读时重建；订单状态查询频繁但更新少，适合短TTL兜底。
比如用户下单后刷新订单页，看到状态没变，多半是因为缓存没更新。这时候前端可以提示“数据刷新中”，后台则通过消息队列异步通知缓存服务清理对应 key，既保证最终一致，又不让接口卡住。
缓存失效不是技术炫技，而是平衡速度和准确的日常抉择。用对了，用户丝滑购物；用错了，轻则页面错乱，重则超卖退款。每个电商业务都在不断调试这套机制，就像调节家里的水温，太烫不行，太凉也不行，得刚刚好。