当前位置：首页 > 问答 > 正文

Redis里那些过期的事儿，怎么实现和用在啥场景上讲讲

黎家
问答
2025-12-30 15:41:21
2

说到Redis里那些“过期”的事儿，这其实是Redis一个非常核心且实用的功能，想象一下，你有一个储物柜，有些东西你只打算临时放一会儿，比如一份外卖，你肯定不希望它一直占着格子直到发霉，Redis的过期机制就是干这个的——给存放在里面的数据设置一个“保质期”，时间一到，Redis就自动帮你清理掉，省心省力。

这功能是怎么实现的呢？

Redis内部用了好几种聪明的办法来管理这些过期键,而不是傻傻地每个键都单独盯着，主要的手段有两种，它们像两个默契的搭档一起工作。

第一种办法叫 “惰性删除” ，这个名字听起来有点懒，但很高效，它的原则是：不见不删，意思是，当一个客户端尝试访问某个键的时候，Redis才会顺便检查一下这个键是否已经过期了，如果过期了，那就立刻删除它，然后返回一个空值给客户端，好像这个键从来不存在一样，这样做的好处是，CPU资源只用在该用的地方，只针对那些被请求的键进行检查，不会浪费资源去扫描那些可能永远不再被访问的过期键。

光靠“惰性删除”有个问题：如果有些键设置过期后，就再也没有被访问过呢？那它们就会像幽灵一样一直留在内存里，占着地方却不干活，造成内存泄漏，为了解决这个问题，Redis派出了第二个搭档：“定期删除”。

“定期删除”可以理解为一个主动的清洁工，Redis会每隔一段时间（默认是每秒10次）随机抽取一小部分设置了过期时间的键，检查它们是否过期，如果过期了就删除，如果发现这次抽查中，过期键的比例很高，它会认为“这片区域垃圾比较多”，于是立即再进行一轮抽查，直到过期键的比例降下来，这种方式是主动的、抽样式的，它保证了即使那些永不访问的过期键，最终也会被清理掉，同时又不会因为全局扫描而导致Redis服务卡顿。

这两种策略相辅相成,“惰性删除”保证了每次读取操作的高效和准确，“定期删除”则是对内存空间的一种主动回收和保障，在绝大多数情况下，这套组合拳都能很好地工作。

这个好用的功能具体能用在哪些地方呢？

应用场景非常广泛,几乎只要是涉及临时数据的地方都能看到它的身影。

用户会话（Session）管理：这是最经典的用法，用户登录网站后，服务器会创建一个Session来记录用户的登录状态，比如用户ID，这个Session不能永久有效，通常用户一段时间不操作（比如30分钟）就应该失效，把Session存到Redis里，并设置30分钟的过期时间，就完美解决了这个问题，用户每次操作就刷新这个过期时间，用户关闭浏览器一段时间后，Session自动清除，安全又省事。
手机验证码或邮箱验证码：当你注册账号或进行敏感操作时，系统会发一个验证码给你，这种验证码通常有效期很短，可能就1分钟或5分钟，把它存进Redis并设置对应的过期时间，时间一到，无论验证成功与否，这个码都自动失效，有效防止被恶意重复尝试或暴力破解。
缓存数据与数据库同步：为了减轻数据库的压力，我们经常把一些频繁读取但又不太变化的数据（比如商品分类、城市列表）缓存在Redis里，如果数据库里的真实数据更新了，缓存里的旧数据就会出问题，这时可以给这些缓存数据设置一个相对较短的过期时间，比如10分钟，这样，即使数据库更新了，缓存最多也只会有10分钟的延迟，之后会自动从数据库拉取最新数据，这是一种简单有效的保证数据最终一致性的方法。
频率限制（限流）：为了防止恶意攻击或滥用，比如防止短信接口被刷，我们可以用Redis来做限流，思路是：给每个IP地址或用户ID设置一个键，记录单位时间内的请求次数，限制每分钟只能请求5次，第一次请求时，设置这个键的值为1，并设置过期时间为1分钟，后续请求来了就给这个键的值加1，如果在一分钟内超过5次，就拒绝请求，一分钟过后，键自动过期，限制重置，这比在程序里写定时任务要简单可靠得多。
分布式锁：在分布式系统中，有时需要确保同一时间只有一个服务实例能执行某个关键操作（比如秒杀时扣减库存），可以用Redis来实现一个简单的分布式锁，获取锁的时候设置一个键，并在操作完成后删除它，但万一持有锁的服务实例崩溃了，没来得及删除锁，就会导致锁永远无法释放（死锁），在设置锁的时候一定要给它加上一个过期时间（比如10秒），这样即使发生了意外，锁也会在10秒后自动释放，其他实例就能继续工作了，避免了系统卡死。
临时活动数据：比如电商平台的限时秒杀活动，活动的开始和结束时间是固定的，可以将秒杀的商品库存信息放在Redis里，并直接将过期时间设置为活动结束的时刻，活动一结束，相关数据自动清理，非常方便。