Redis里数据怎么自动过期的，顺便聊聊各种用到过期功能的场景

关于Redis里的数据是怎么自动过期的,其实它的核心机制并不复杂，我们可以把它想象成一个给数据贴上了“保质期”标签的系统，这个系统主要靠两种简单的方法来协同工作，一种是“惰性删除”，另一种是“定期删除”。（来源：Redis官方文档对过期机制的描述）

惰性删除，这个名字听起来有点懒，实际上它的行为也确实如此，它不会主动去检查所有数据是否过期，而是等到有人来访问这个数据的时候，才顺便检查一下它是否已经“变质”了，你设置了一个键值对，并给了它10分钟的存活时间，在接下来的9分钟内，如果没有人来读取这个键，Redis就完全不理它，直到第10分钟以后，某个客户端尝试来读取这个键时，Redis才会猛地想起来：“哦，让我看看这个键过期没……哎呀，已经过期了！”然后它就会立刻把这个过期的键删除掉，并且告诉客户端“这个键不存在”，这种方式的好处是节省CPU资源，只在必要的时候才干活，但坏处也很明显，如果一个过期的键永远不再被访问，那么它就会一直占着内存，成了“僵尸数据”，这就造成了内存的浪费。

正因为惰性删除有这种缺陷,所以Redis还需要一个更主动的机制来辅助，这就是定期删除，你可以把它理解成一个比较勤快的“保洁员”，它会每隔一段时间（默认是每秒10次）就主动巡逻一下，随机抽取一部分设置了过期时间的键，检查它们是否已经过期，如果发现过期的键，就把它清理掉，这个保洁员很聪明，它不会一次性地检查所有键（那样会卡住整个系统），而是每次只检查一小部分，通过这种高频率的、分批次的随机抽查，它能够逐渐地清理掉那些长期无人问津的“僵尸数据”，保证了内存能够被有效地回收。（来源：Redis官方文档对过期机制的描述）

Redis的过期功能就是靠着这个“懒汉”（惰性删除）加“勤快人”（定期删除）的组合拳来实现的，两者互补，既避免了持续检查带来的性能开销，又能及时清理垃圾数据。

在哪些实际场景下我们会用到这个好用的过期功能呢？其实它在我们的日常开发中无处不在。

第一个最经典的就是用户登录凭证的缓存，比如用户登录网站，服务器生成一个Session信息或者一个Token（令牌），通常我们希望用户登录状态能保持一段时间，比如一天或者一周，这时我们就可以把这个Token作为键，用户信息作为值，存到Redis里，并设置一个24小时或168小时的过期时间，这样，用户每次请求时，我们检查这个Token是否有效且未过期，一旦用户长时间不活动，或者过了设定的期限，这个Token就会自动失效被删除，用户就需要重新登录，这既保证了安全性，又省去了我们手动清理过期Session的麻烦。

第二个常见的场景是手机或邮箱的验证码，验证码的核心特点就是“短时有效”，通常只有60秒或300秒，当我们把验证码和手机号作为键值对存入Redis时，一定会设置一个相应的短过期时间，时间一到，无论这个验证码被使用与否，它都会自动消失，这完美地契合了业务需求，防止了验证码被恶意地无限次尝试，也避免了无效数据长期堆积。

第三个是应对高频访问的缓存数据，比如一个电商网站的商品详情页，为了减轻数据库的压力，我们会把商品信息缓存在Redis里，但是商品信息并不是一成不变的，可能会调价、会下架，如果我们设置永久缓存，数据就不准确了，这时候，我们可以给这个缓存设置一个相对较短的过期时间，比如5分钟，这意味着，即使后台更新了商品价格，最坏的情况也只需要5分钟，缓存失效后重新从数据库加载，就能看到最新的价格，这是一种在数据实时性和系统性能之间取得平衡的简单有效策略。

第四个是进行简单的频率限制，也就是我们常说的“限流”，比如为了防止恶意刷接口，我们规定同一个IP地址在一分钟内只能请求某个API 60次，我们可以以IP地址为键，每来一次请求就把计数器加1，并设置一分钟的过期时间，这样，在一分钟内，计数超过60就拒绝服务，而一分钟过后，这个键自动过期，计数器从零开始，新的一分钟又重新计算，这个功能用Redis的过期来实现就非常简洁优雅。

还有一些临时的、一次性的数据也适合用过期功能，比如一个临时的购物车，用户可能把商品加进去但一直没下单，我们可以设置一个长达几天的过期时间，如果用户一直不处理，系统就自动清空，或者是一些后台任务的中间状态、分布式锁等，都可以利用过期特性来避免资源被永久占用。

Redis的自动过期是一个非常实用且核心的特性,它通过巧妙的设计平衡了性能和资源消耗，在我们设计系统时，但凡遇到带有“临时”、“短期”、“一次性”或者需要“自动清理”这些关键词的数据，都可以优先考虑使用Redis的过期功能来解决。