Redis缓存时间怎么设置才合适，缓存过期那些事儿你知道吗

Redis缓存时间怎么设置才合适,缓存过期那些事儿你知道吗？这个问题几乎是每个使用Redis的开发者都会遇到的经典难题，设短了，数据库压力大；设长了，数据可能不及时，今天我们就来聊聊这事儿，抛开那些复杂的概念，用大白话讲明白。

最核心的问题：缓存时间（TTL）设多久？答案可能让你失望：没有一刀切的标准答案，这完全取决于你的业务场景和数据特性，但别急，有一些通用的思路和策略可以帮你做出合适的选择。

根据数据的变化频率来定

这是最根本的原则,你可以把你的数据分成几类：

1. 几乎不变的数据：比如商品的分类目录、城市列表、系统配置项，这种数据一旦生成，很长时间都不会变，对于它们，缓存时间可以设得非常长，比如24小时、7天，甚至更长，极端情况下，如果确定永远不变，可以不设置过期时间，但要注意万一需要更新，得有手动清理缓存的机制。
2. 变化频率较低的数据：比如用户的基本信息、文章的详情页，用户不会每分钟都改昵称，文章发布后内容也基本固定，这类数据的缓存时间可以设置在一个适中的范围，比如1小时到12小时，这样既能大幅降低数据库压力，也能保证在可接受的时间内读到最新数据。
3. 变化频繁的数据：比如股票实时价格、新闻网站的首页热点排行、商品的库存数量（在秒杀场景下），这类数据对实时性要求很高，缓存时间要设得很短，比如1分钟、10秒，甚至更短，我们甚至不是靠TTL过期，而是直接在数据源变更时，主动更新或删除缓存（这涉及到更复杂的缓存策略，如Cache-Aside或Write-Through）。
4. 完全实时或准实时的数据：比如用户的购物车、聊天消息，这类数据通常不适用缓存，或者只能使用极短时间的缓存（几秒钟），因为要求强一致性。

考虑业务的容忍度

除了数据本身的变化,还要看业务能接受多长时间的“脏数据”。

• 对管理员：比如后台统计报表，晚几分钟甚至几小时看到数据，通常是可以接受的，缓存时间可以设长一些。
• 对普通用户：比如看到一篇新闻，晚一两分钟更新影响不大，但如果是抢购时看到的库存，差一秒都可能出问题，你要评估一下，如果你的数据晚更新5分钟，用户会投诉吗？如果不会，TTL就可以大胆点。

一些实践中的小技巧和坑

1. 避免缓存“雪崩”：想象一下，如果你把一万个缓存数据的TTL都设置为标准的30分钟，那么半个小时后，这些数据很可能在同一瞬间全部失效，这时，一万个请求会同时砸向数据库，数据库很可能就直接挂掉了，这就是“缓存雪崩”，解决方法很简单：给缓存时间加个随机值，基础时间是30分钟，然后加上一个0到5分钟的随机数，这样，缓存就会在30到35分钟之间的不同时刻陆续失效，压力就被均匀分散了。
2. 不同的数据结构，不同的过期策略：Redis的过期策略是针对整个key的，如果你在一个Hash或者Set里存了很多子项，你无法为单个子项设置不同的TTL，如果子项的生命周期不同，更好的做法是为它们分配不同的key。
3. 内存不足时的淘汰策略：当Redis内存用完时，它需要淘汰一些旧数据来存放新数据，这时的行为取决于你配置的maxmemory-policy（最大内存策略），常见的策略有：
   • volatile-lru：从设置了过期时间的key中，淘汰最近最少使用的。
   • allkeys-lru：从所有key中，淘汰最近最少使用的。
   • volatile-ttl：从设置了过期时间的key中，淘汰存活时间（TTL）最短的。
   • noeviction：不淘汰，新写入操作会报错。 根据你的业务重要性来选择，如果有些核心数据绝对不能丢，即使用户不常访问，可以考虑使用volatile-lru或volatile-ttl，并只为非核心数据设置TTL，如果所有数据都可以被淘汰，那就用allkeys-lru。

别忘了“缓存穿透”和“缓存击穿”

这两个概念也和过期时间有关。

• 缓存穿透：查询一个根本不存在的数据（比如不存在的用户ID），因为不存在，所以缓存里永远没有，请求每次都落到数据库上，解决方法：即使查不到，也在缓存里存个空值（比如null），并设置一个较短的过期时间（比如1-5分钟），防止恶意攻击。
• 缓存击穿：某个热点key突然过期了，此时大量请求同时进来，全都打到数据库上，解决方法：可以用互斥锁（分布式锁），保证只有一个请求去数据库加载数据，其他请求等待并直接读取更新后的缓存。

总结一下

设置Redis缓存时间,是一个权衡的艺术，你要在数据库压力和数据实时性之间找到一个平衡点，核心思路就是：看数据变的快不快，看业务急不急，用加随机数防止雪崩，用存空值应对穿透，用锁来缓解击穿。

一开始可能拿不准,没关系，可以先设一个你认为合理的时间，然后观察系统的监控指标：缓存命中率、数据库QPS（每秒查询率），如果命中率太低，说明缓存时间可能设短了；如果数据库QPS峰值很高，可能是有雪崩或击穿风险，根据这些反馈不断调整，你就会越来越有经验，缓存策略不是一成不变的，要随着业务的发展而优化。

---来源：综合自《Redis设计与实现》、美团技术博客、以及常见的后端开发实践经验分享。