Redis超时时间怎么调才能让性能更好一点，聊聊那些设置的小技巧

关于Redis超时时间的调整，要想让性能更好一点，其实核心思路就一句话：别让数据在Redis里“死”得太随意，也别让它们“赖”着不走。 这就像管理一个仓库，你得及时清掉没用的废品腾出空间，但又不能把偶尔还要用的宝贝给扔了,下面我们就聊聊几个具体的小技巧。

第一，最关键的是区分“冷热”数据，别一刀切。

很多人图省事，可能会给所有的键设置一个统一的过期时间，比如全都设为24小时，这样做虽然简单，但性能上往往不是最优的，根据Redis官方文档（Antirez以及后来的Redis Labs维护团队在其博客和文档中多次强调）的建议,最有效的做法是根据数据的访问频率来设置不同的超时时间。

• 热点数据：比如首页的焦点图、秒杀活动的商品信息，这些被频繁访问的数据，超时时间可以设得长一些，甚至不设置过期（如果数据本身不会变的话），目的是减少因为缓存失效而穿透到数据库的请求,减轻后端压力。
• 冷门数据：比如用户上次登录的日志、一些临时的会话状态，这些数据访问一次后可能很久都不会再用，对这类数据，应该设置一个相对较短的超时时间，比如几分钟或几小时,让Redis能及时回收内存。

第二，避免“缓存雪崩”，给过期时间加个随机数。

想象一下，如果你在某个时间点批量导入了大量数据，并且都给它们设置了相同的过期时间，比如2小时，那么2小时后的那一刻，这些数据会同时失效，这时，如果有大量请求涌进来，发现缓存都失效了，就会全部直接打到后端的数据库上，数据库很可能瞬间就被压垮了，这种现象就叫“缓存雪崩”。

《Redis设计与实现》这本书里提到了一个很实用的小技巧：在设置过期时间时，不要直接用固定的数值，而是在这个数值基础上加上一个随机的偏移量。 原本想都设成1小时过期，现在可以改成“1小时 + (0到10分钟之间的一个随机数)”，这样就能把大量键的过期时间打散，避免它们在同一时刻集体失效，像排队一样分批过期,对后端数据库的压力就小多了。

第三，理解Redis淘汰数据的内存回收策略，配合超时时间使用。

Redis的内存是有限的，当内存用满时，它需要根据一定的策略（Maxmemory-policy）来淘汰一些数据，以便写入新数据，这个策略的选择，和你设置超时时间是紧密相关的,在Redis的配置文件里可以看到这些策略。

• 如果你的大部分数据都设置了合理的超时时间，那么可以优先选择 volatile-lru 或 volatile-ttl 这类策略。
  • volatile-lru：从已设置过期时间的键中,挑最近最少使用的那个淘汰掉。
  • volatile-ttl：从已设置过期时间的键中，挑剩余生存时间最短的那个淘汰掉。 这两种策略都能很好地利用你设置的超时时间，volatile-ttl 更是“按计划”清理数据,非常高效。
• 如果你有些键根本没设置过期时间（比如一些重要的基础数据），但又怕内存爆掉，那么可以选择 allkeys-lru，它会从所有键中淘汰最近最少使用的，这样可以保证最重要的数据（被频繁访问的）能留下来。

调整超时时间的时候，要想想你打算用哪种内存淘汰策略,它们是搭档。

第四，对于永不超时的数据，要特别小心。

有些数据我们可能觉得永远有效，就不设超时时间，但这有个隐患：如果业务逻辑发生变化，这些数据需要更新或失效，你只能通过手动删除键来处理，不够灵活，一个更好的小技巧是，即使认为是“永久”的数据，也可以设置一个非常长的超时时间，比如一个月或者一年，这样做的好处是，万一出了什么问题，最坏的情况它也会在一个月后自动消失，相当于一个保险机制，在代码里，每次使用这个键之前，可以主动判断一下是否需要更新,如果需要就重新写入并重置这个很长的超时时间。

第五，监控和观察是永远的法宝。

所有的小技巧都不是一劳永逸的，你需要观察Redis的监控指标，expired_keys（已过期的键数量）和 evicted_keys（因内存满被驱逐的键数量）。evicted_keys 持续增长，说明内存不够用，淘汰策略在频繁工作，可能就需要你优化超时时间或者扩容了。expired_keys 在某段时间内激增，可能就是你遇到了上面说的“缓存雪崩”的苗头。

调优Redis超时时间，不是找个万能数字填上去就行，它更像是一门平衡的艺术：在保证热点数据命中率的同时，及时清理垃圾，并避免对后端系统造成突发压力。 核心就是区分冷热、打散过期、配合内存策略、给“永久”数据上保险,并且持续观察效果。