Redis里怎么搞时间过期那些事儿，实际用起来的场景和技巧分享

Redis里怎么搞时间过期那些事儿，实际用起来的场景和技巧分享

直接说核心，Redis里给数据设置过期时间，主要就靠两个命令：EXPIRE（给已有的key设置过期时间）和SET的时候直接加EX参数（比如SET key value EX 60），这就像是给数据上了个闹钟，时间一到，数据就自动被删掉了,这个机制是Redis作为缓存工具最核心的功能之一。

实际用起来的场景，那可太多了：

1. 最典型的——手机验证码。 你收到的短信验证码，比如设置60秒后过期，用Redis存再合适不过，键可以是“login:code:13800138000”，值就是验证码，设置60秒过期，时间一到，这个码就没了，既安全又省去了自己写清理代码的麻烦。（这个例子在几乎所有教程里都会提到,是经典场景）
2. 用户会话（Session）管理。 用户登录网站，会生成一个登录状态（Session），把这个状态存到Redis里，并设置一个比如30分钟的过期时间，用户每次操作，都把这个时间续期一下，如果用户30分钟没动静，这个Session自动失效，用户就需要重新登录,这比存到服务器内存里要可靠和方便得多。
3. 热点数据的临时缓存。 比如一篇爆款新闻文章，访问量巨大，从数据库查压力太大，我们可以把它存到Redis里，设置一个相对较短的时间，比如10分钟，这样在10分钟内，所有请求都直接从超快的Redis里读取，10分钟后数据过期，下一个请求会重新从数据库加载并缓存一个新的10分钟，这样既保证了速度，又不会让数据一直占用内存,还能保证数据不会太旧。
4. 频率限制（限流）。 比如防止短信接口被刷，限制一个手机号1分钟内只能发1次，可以用这个手机号作为key，值随便设，设置60秒过期，每次发送前，用SETNX命令（只有key不存在时才设置）去尝试创建这个key，如果创建成功了，说明1分钟内没发过，就执行发送，如果创建失败，说明这个key还在（1分钟还没过），就拒绝发送,这个技巧非常巧妙和高效。
5. 简单的分布式锁。 虽然专业的分布式锁更复杂，但一些简单场景可以这么做：比如一个定时任务只能由一台服务器执行，所有服务器都尝试用SETNX命令设置同一个key（task:lock”），并给这个key设置一个较短的过期时间（比如30秒），谁设置成功了，谁就获得了锁去执行任务，执行完后，自己删除这个key，即使获得锁的服务器意外崩溃，因为这个锁有过期时间，30秒后会自动释放，避免了死锁，不过要注意，这只是一个基础模型，严谨的实现还需要处理更多细节（根据《Redis官方文档》对分布式锁的说明，这只是一个最简思路）。

一些技巧和需要注意的坑：

• 别以为到期立刻就没。 Redis删除过期key主要有两种方式（根据《Redis设计与实现》一书中的描述）：一是“惰性删除”，等你来读这个key的时候，才发现它过期了，顺手删除；二是“定期删除”，Redis每隔一段时间随机抽查一些key，清理掉过期的，有可能一个key已经过期了，但它还在内存里躺着一小会儿，直到被检查到或再次被访问，这对大多数业务没问题，但如果你对“精确准时”有极端要求,就得心里有数。
• 小心“缓存雪崩”。 如果你在某一时刻，同时设置了大量key，并且给了相同的过期时间（比如都在凌晨2点过期），那么当这个时间点到来时，这些key集体失效，会导致所有请求瞬间都砸向数据库，数据库可能就挂了。技巧是：在设置过期时间时，加一个随机值。 比如本来是缓存1小时，你可以改成“1小时 + 随机0到300秒”，这样key的过期时间就分散开了,避免集体失效。
• “用”了它，就给它续个期。 对于像用户Session这种场景，我们希望用户只要在活跃，Session就一直有效，可以在每次处理用户请求时，都对这个Session的key执行一个EXPIRE命令，重新设置为30分钟，这样活跃用户的Session就会一直延续,不活跃的则自动清理。
• 用SCAN代替KEYS来管理。 有时候我们需要查看或清理一批带有特定前缀的key（比如所有以“user:session:”开头的），千万不要在生产环境用KEYS *这个命令，它会阻塞整个Redis服务，应该使用SCAN命令来渐进式、非阻塞地遍历，这是一个非常重要的运维技巧（Redis官方文档强烈警告不要在生产使用KEYS命令）。

Redis的过期机制用起来很简单，但想用好，得结合具体业务场景，并避开那些潜在的坑，它不仅仅是“自动删除数据”，更是构建安全、高效、可靠应用的一个非常趁手的工具，多想想“这个数据多久不用就可以扔了？”,很多场景就能自然地用上它了。