Redis里过期时间怎么算才准，控制起来又不慌乱的那些事儿

说到Redis里设置过期时间这件事,乍一看很简单，不就是个EXPIRE命令嘛，设个秒数就完事了，但真要在实际项目里把它用得准、用得稳，不让它成为半夜告警的“罪魁祸首”，还真有不少需要琢磨的地方，咱们今天就不聊那些深奥的源码，就说说怎么算这个时间，以及怎么管理才能心里不慌。

第一件事：别拍脑袋定时间，要从业务逻辑出发

很多人设置过期时间很随意,觉得缓存嘛，随便放个几分钟好了，这其实是个误区，过期时间的长短，根本依据应该是业务数据的变化频率和你能容忍的数据延迟。

• 高频变化且要求实时性高的数据：比如电商商品的库存，可能秒秒钟都在变，这种数据其实不太适合用缓存，如果非要用，过期时间要设得非常短，比如几秒到几十秒，而且要做好数据不一致的兜底方案，这时候，时间不是“算”出来的，是根据业务容忍度“定”出来的。
• 低频变化但重要的数据：比如用户的个人资料信息，用户不会天天改头像和昵称，但一旦改了，希望立即生效，对于这种，可以设置一个相对长的时间，比如1小时或者12小时，在用户主动更新资料的后台代码里，在更新数据库之后，要紧接着执行一个DEL命令删除掉对应的缓存（这叫做“延迟双删”策略的一部分），这样，下次读取时自然就会从数据库加载新数据并重新缓存，这里的1小时，是一个平衡点，既减少了数据库压力，又保证了数据不会长期脏掉。
• 几乎不变的数据：比如城市列表、商品分类等基础数据，这些数据可能几个月才变一次，它们的过期时间可以设得非常长，比如7天、30天，甚至可以采用“永久缓存+后台手动触发更新”的策略，设置长过期时间主要是为了预防万一，避免缓存永远不失效导致极端情况下无法自动更新。

你看,过期时间不是技术决定的，是业务场景决定的，先想清楚“这数据多久会变？”和“它变了之后，多久被用户看到是能接受的？”，答案就出来一大半了。

第二件事：给过期时间加点“随机数”，避免缓存雪崩

这是非常关键的一招,想象一个场景：你在系统启动时，预热了一大批用户数据到Redis，并且都给它们设置了同样的过期时间，比如30分钟，那么30分钟后，这批缓存会在同一时刻集体失效，紧接着，所有的请求都会瞬间砸向数据库，数据库很可能承受不住这么大的压力而挂掉，这就是可怕的“缓存雪崩”。

怎么避免？就是在设置过期时间时，加一个随机值，原本要缓存30分钟，你不要直接设EXPIRE key 1800，而是可以这样算：基础时间 + 一个范围内的随机时间。

举个例子： 过期时间 = 30分钟 + (0到5分钟之间的一个随机数) 这样，这批key的过期时间就会均匀地分布在30到35分钟这个区间里，虽然第一批缓存失效的请求还是会回源数据库，但压力是逐步到来的，给了数据库喘息的机会，完美地避免了集体失效的惊悚场面，这个方法简单又有效，是必备的实践。

第三件事：用了LRU淘汰策略，过期时间也别太任性

Redis在内存不足时,会启用淘汰策略来删除一些key腾地方，常用的策略是allkeys-lru或volatile-lru，意思是淘汰最近最少使用的键。

这里有个小细节要注意：Redis的过期删除是惰性的加上定期的，惰性删除是说，只有当某个key被访问时，才会检查它是否过期，过期就删，定期删除是Redis每隔一段时间随机抽查一些key删除过期的，这意味着，如果一个已过期的key一直没人访问，它可能会在内存里残留一段时间。

如果你的系统缓存量巨大,内存经常处于紧张状态，而你给一些不重要的key设置了很长的过期时间（比如24小时），那么这些key即使再也没人用，也会因为没到期而长时间占据着内存，可能导致那些更重要的、频繁使用的key因为内存不足而被LRU淘汰掉。

在内存紧张的环境中,对于访问频率不确定的缓存，与其设一个很长的过期时间，不如设一个短一点的（比如1小时），然后依靠Redis的淘汰机制，如果这个数据确实重要，被淘汰后下次访问自然会重新加载缓存；如果不重要，那就让它尽快被淘汰掉，把内存让出来，这叫用空间的流动性来换取的稳定性。

第四件事：管理上千个key的过期时间，得有章法

当项目大了,缓存key成千上万，如果每个key的过期时间都散落在代码的各个角落，后期想统一调整或者排查问题简直就是噩梦，管理过期时间本身也需要管理。

1. 集中配置：不要硬编码，可以把不同类型的缓存的默认过期时间定义在统一的配置文件中（比如Apollo、Nacos这样的配置中心，或者一个简单的配置文件），在代码里，通过一个统一的缓存工具类来读取配置并设置过期时间，这样，哪天你想把用户信息的缓存时间从1小时调到2小时，只需要改一下配置中心，而不用去翻代码、发版。
2. Key的命名规范：给key命名时，最好包含业务前缀和版本号，比如user:v1:info:123，这样一方面清晰，当你想整体清理某类缓存或者升级缓存结构时，可以通过KEYS user:v1:*这样的模式来批量操作（生产环境慎用KEYS，可以用SCAN命令替代），或者直接通过配置新版本号v2来让旧缓存自然过期。
3. 设置和续期逻辑：对于某些特别关键的数据，可以考虑使用“续期”策略，不是在写入时设一个长过期时间，而是设一个较短的时间（比如10分钟），然后另起一个后台任务，定期（比如每5分钟）去检查并刷新这些关键key的过期时间（使用EXPIRE命令重新设置为10分钟），这样能保证只要系统在运行，这些关键数据就一直在缓存里，即使任务挂了，缓存也会在最多10分钟后失效，不会造成永久性的脏数据。

让Redis过期时间又准又稳,核心就四点：依据业务定长短，加上随机防雪崩，结合内存策略做权衡，最后通过规范来管理，把这些事儿做到位了，你再看Redis里的TTL（生存时间），心里肯定就踏实多了。