Redis查询缓存时间怎么搞，深入又简单讲给你听点啥

想象一下,你有个小卖部（你的应用），仓库（数据库）在很远的地方，每次顾客要买瓶水，你都得跑回仓库去拿，累个半死，于是你在小卖部里摆了个冰柜（Redis缓存），先把一些常用的饮料从仓库搬过来放着，这样顾客要买水，你直接从冰柜拿，快多了。

那问题来了,这些饮料放在冰柜里能一直卖吗？当然不行，有些酸奶过几天就过期了，你得定期清理，这个“过期时间”，就是Redis缓存的核心，设得太短，你老得跑仓库，冰柜白买了；设得太长，顾客可能买到过期酸奶，拉肚子了（读到脏数据）。

搞明白怎么设这个时间,特别关键，Redis主要给了你两种武器来设定“保质期”。

第一种武器：给每个商品贴保质期标签（TTL - Time To Live）

这是最常用、最直接的方法，就像你给每瓶酸奶贴上“请在2024年10月1日前饮用”，在Redis里，你有两个主要命令来干这个事儿：

1. SET key value EX seconds：这是最推荐的用法，一步到位，比如你缓存一个用户信息，命令是 SET user:123 '{"name":"张三"}' EX 3600，这意思就是，把用户123的数据放进缓存，同时规定它只能活3600秒（1小时），1小时后，这个数据会自动消失。
2. EXPIRE key seconds：这个命令是事后补救，比如你先用 SET user:123 '{"name":"张三"}' 把数据存进去了，但忘了设时间，后来想起来了，就可以用 EXPIRE user:123 3600 给它补上一个1小时的寿命。

这两种方式效果一样,但第一种更常用，因为它能保证原子性（就是说SET和EXPIRE两个操作要么一起成功，要么一起失败，不会出现存了数据却没设成时间这种尴尬情况）。

第二种武器：设定一个统一的深夜检查时间（过期策略）

光给每个商品贴标签还不够,万一你忘了清理呢？Redis自己有个后台的“值班大爷”，他会定期在深夜（Redis空闲时）去冰柜里检查，把过期的商品扔掉，这个大爷的检查频率和扔东西的狠劲儿，你是可以调的，这就是Redis的内存淘汰策略，用 maxmemory-policy 配置。

这个策略在你整个冰柜（Redis内存）快要满了的时候特别有用。

• volatile-lru：大爷只检查那些贴了保质期标签的商品（设置了TTL的key），然后扔掉其中最久没被卖出的那个（Least Recently Used），这个非常常用，保证了热门商品能一直留着。
• volatile-ttl：大爷还是只检查有保质期的，但这次他更“科学”，哪个商品离过期时间最近，就先扔哪个。
• allkeys-lru：大爷发狠了，不管有没有贴保质期标签，只要冰柜满了，就扔掉所有商品里最久没人动的。
• noeviction：大爷直接摆烂，不扔了，下次你再想往满的冰柜里放新货，他就告诉你“没地儿了，放不下”，这个策略能保证数据不丢，但容易导致你的存数据操作失败。

生产环境常用 volatile-lru，因为它能在内存不足时优雅地清理掉“可丢弃”的缓存数据，保证核心服务。

最灵魂的问题来了：这个缓存时间到底设成多少秒？

没有标准答案,全靠你对业务的了解，但有几个原则：

1. 看数据变化频率：像全国省份列表这种几乎不变的数据，你设个一天、一周甚至更长都行，像用户昵称、文章点赞数这种可能变化的数据，时间就要短点，比如几分钟到一小时，如果是股票实时价格，那可能只能设几秒钟。
2. 平衡用户体验和数据库压力：时间设长点，用户感觉快，但可能看到的数据不是最新的，时间设短点，数据新鲜，但数据库压力大，速度可能慢，你要找个平衡点，比如新闻网站首页，设5分钟，大部分用户都能接受。
3. 用“延迟双删”应对极端情况：这是个高级技巧，想象一下，你刚更新了数据库里的用户信息，然后顺手把缓存里旧的数据删了（让下次请求能读到新的），但万一在“更新数据库”和“删除缓存”这个极短的空隙里，另一个请求发现缓存没了，就去数据库读了旧数据并又塞回缓存了呢？这就导致缓存里一直是脏数据，解决办法是“延迟双删”：更新数据库 -> 立即删一次缓存 -> 等个几百毫秒（比如500ms，确保前面可能的旧读请求都完事了） -> 再删一次缓存，这样能大概率保证最终一致性。

最后总结一下：

搞Redis缓存时间,就像经营小卖部的冰柜，核心就两步： 第一，给大多数缓存数据设一个合理的TTL（用 SET ... EX），这个时间根据数据会不会变、变得多快来定。 第二，配置好内存淘汰策略（volatile-lru），给Redis一个“兜底方案”，防止内存撑爆。

这样一搞,你的应用就能又快又稳了，缓存是为了提速，但不能因为图快而吃了“过期酸奶”，得不偿失，多根据自己业务的实际情况去试、去调整，慢慢就能找到最适合的那个时间点。