缓存失效策略与定期同步数据如何配合使用

你有没有遇到过这种情况：刚在后台更新了商品价格，刷新页面却发现还是旧的？或者用户反馈说看到的信息明明已经改了，但系统里就是不生效。问题很可能出在缓存上。

缓存能大幅提升系统响应速度，比如把数据库里的热门数据放在 Redis 里，下次读取就不用再查数据库。但好处背后也有代价——数据可能“太新鲜”或“太老旧”。如果缓存一直不更新，用户看到的就是过时信息。

为了让缓存和真实数据保持一致，我们需要设置合理的失效策略。最简单的做法是设置 TTL（Time To Live），比如让缓存 5 分钟后自动过期：

redis.setex("product:1001", 300, "{\"price\": 89.9}")

这样每 5 分钟缓存自动清掉，下一次请求会重新从数据库加载最新数据。适合变化不频繁的内容，比如文章详情、配置信息。

有些数据一改就必须立刻生效。比如促销活动开始前调低了价格，不能等 5 分钟后才更新。这时候可以在更新数据库的同时，主动删除对应缓存：

// 更新数据库
updateProductPrice(1001, 69.9);
// 删除缓存
redis.del("product:1001");

下次请求时发现缓存没了，自然会去查数据库并重建缓存。这种方式反应快，但万一删缓存失败，就会留下脏数据。

为了防止手动清除出错或漏掉，可以加一个定时任务，每隔一段时间强制刷新一批关键缓存。比如每天凌晨两点，把所有参与活动的商品缓存重新生成一遍。

const schedule = require('node-schedule');
// 每天凌晨2点执行
schedule.scheduleJob('0 2 * * *', function(){
  refreshPromoCache();
});

这种定期同步像是给系统上了道保险。即使平时的失效机制出了问题，定时任务也能把数据拉回正轨。

实际项目中，往往不是只用一种方法。比如商品详情页采用“TTL + 主动删除 + 定时同步”三重保障：

多管齐下，既保证实时性，又避免因异常导致的数据错乱。

缓存不是设完就高枕无忧的事。合理的失效策略加上定期同步机制，才能让数据始终靠谱。别让用户的“刷新”成为检验系统健康的唯一手段。

缓存失效策略与定期同步数据：让系统更稳定的小技巧