缓存过期时间怎么设置：从场景到实操的实用指南

在日常开发中，缓存用得多了，问题也就跟着来了。比如商品详情页明明更新了价格，用户刷了半天还是旧价，八成是缓存没过期。这时候就得琢磨：缓存过期时间怎么设置才合理？

别一上来就设24小时

很多人图省事，给所有缓存统一设个24小时过期。听起来挺省心，实际用起来坑不少。新闻资讯类内容可能几小时就失效了，硬撑一天用户看到的就是过时消息；而一些静态配置，比如城市列表，几天都不变一次，设两小时反而增加数据库压力。

根据数据变化频率定策略

动态强的数据，比如秒杀库存，建议设置较短的过期时间，比如30秒到1分钟。这样即使缓存没及时更新，用户等待的时间也不长。像用户个人资料这种读多写少的内容，可以设长一点，比如2小时或更久。

举个例子，电商平台的商品分类菜单几乎不变，缓存6小时没问题。但促销活动倒计时每秒都在变，这类数据就不适合长期缓存，宁可不缓存，或者配合主动删除机制来处理。

结合主动删除更灵活

光靠过期时间不够稳妥。比如后台修改了文章内容，不可能等缓存慢慢过期才生效。这时候应该在数据更新时，直接删除对应的缓存 key，让下一次请求重新加载最新数据。

以 Redis 为例，常见的操作是：

SET article:123 "这是一篇新文章" EX 3600
DEL article:123

EX 3600 表示设置60分钟过期，而 DEL 则是在内容更新时立即清除旧缓存，确保用户看到的是最新的。

考虑缓存击穿和雪崩

如果大量缓存同时过期，瞬间请求全压到数据库，容易造成服务卡顿甚至崩溃。为了避免这种情况，可以在设置过期时间时加点随机性。比如基础时间是30分钟，再加一个0到300秒的随机偏移。

Python 示例代码：

import random
expire_time = 1800 + random.randint(0, 300)
redis_client.setex("user:profile:1001", expire_time, data)

这样不同 key 的过期时间会错开，避免集体失效带来的冲击。

监控和调整才是常态

没有一劳永逸的过期策略。上线后要观察缓存命中率、数据库负载和用户反馈。命中率一直很低，可能是过期太短或 key 设计不合理；数据库突然变慢，可能就是缓存大面积失效了。定期查看日志和监控图表，才能动态优化过期时间设置。