Redis数据过期怎么搞，场景里那些必须知道的套路和细节分享

综合自多位资深开发者的技术博客与社区讨论,如阿里云开发者社区、掘金、Stack Overflow 等平台上的相关分享）

Redis 的数据过期功能，说白了就是给存进去的数据设置一个“保质期”，时间一到，Redis 就会自动把这数据给扔掉，这个功能听起来简单，但要用得好，不让它出岔子，里头有不少门道和容易踩的坑，咱们就聊聊在实际项目里，你必须知道的那些套路和细节。

核心就两条命令，但用法有讲究

设置过期,最常用的就是 EXPIRE key seconds 命令，EXPIRE user:123:session 1800，就是让这个用户会话数据在半小时后失效，还有一个是直接在设置值的时候就把过期时间绑上，SET key value EX seconds，一步到位，更常用。

这里第一个细节就来了：过期时间是以秒为单位的整数，你想设置毫秒？有专门的 PEXPIRE 和 SET … PX … 命令，但大部分场景下，秒级精度足够了。

数据是怎么被“扔掉”的？这决定了系统的稳定性

这是最关键的套路,很多人以为数据一到点就立刻被删除了，其实不是，Redis 用的是 惰性删除 和 定期删除 两种策略结合的办法，这里面水很深。

1. 惰性删除（Lazy Way）：当客户端尝试访问一个 key 时，Redis 才会顺便检查一下它是否过期了，如果过期，就当场删除，然后返回一个空值给客户端，这个策略的好处是省 CPU，只在必要的时候干活，但坏处也很明显：如果一个过期的 key 永远没人来访问，那它就永远占着内存不释放，成了“僵尸数据”，这是内存泄漏的主要风险点。

   

2. 定期删除（Proactive Way）：为了解决惰性删除的漏洞，Redis 会每隔一段时间（默认是每秒10次）随机抽取一批设置了过期时间的 key（默认是20个），检查并删除其中已过期的，然后如果发现这批 key 里过期比例超过25%，它就立即再抽20个，循环往复，直到过期比例降下来，这个细节非常重要！

这意味着什么？意味着如果你的 Redis 实例里，在同一时刻有海量的 key 同时过期，Redis 的定期删除线程可能会陷入一个持续的循环检查中，因为每次抽查的过期比例都很高，导致 CPU 短时间内被这个任务占满，可能会影响到处理正常命令的性能，这就是一个典型的“套路”：避免大量 key 在同一秒内集中过期，不要把缓存数据的过期时间都设为相同的固定值（比如都是凌晨2点过期），最好加上一个随机扰动，基础时间 + random(0, 300) 秒，让过期时间散开。

你得知道数据可能“死得不彻底”

由于是惰性删除,你通过 KEYS * 命令（生产环境慎用！）或者一些扫描工具，可能会看到一些已经逻辑过期但物理上还没被删除的 key，判断一个 key 是否还存在，不要依赖这种扫描，最好直接用 EXISTS 命令，因为它会触发惰性删除。

持久化时的过期处理，关系到数据恢复

这也是个大坑,Redis 有两种持久化方式：RDB 和 AOF。

• RDB（快照）：在创建 RDB 快照时，过期的 key 是不会被保存进去的，所以当你用 RDB 文件恢复数据库时，里面根本不会有任何过期数据，很干净。
• AOF（日志）：AOF 文件会记录所有的写命令，包括设置过期时间的命令（EXPIRE），当 Redis 重启后，通过重放 AOF 文件来恢复数据，当重放到 EXPIRE 命令时，如果发现 key 已经过期，Redis 会通过一种“模拟客户端访问”的方式，触发惰性删除，把这个 key 删掉，所以最终恢复出来的数据库状态也是不含过期 key 的。

但这里有个细节：在 AOF 重写时（比如执行 BGREWRITEAOF），Redis 会生成一个新的、精简的 AOF 文件，这个过程和生成 RDB 类似，过期的 key 不会被写入新的 AOF 文件，这保证了 AOF 文件的效率。

实战中的经典套路场景

1. 验证码缓存：这是过期功能的完美场景，设置一个 key 为 captcha:手机号，value 是验证码，过期时间设为 5 分钟，5分钟后自动消失，安全省心。
2. 会话（Session）管理：用户登录后，将 Session 信息存入 Redis 并设置过期时间（如30分钟），每次用户活动都刷新这个过期时间（用 EXPIRE 命令），实现“滑动过期”，如果用户30分钟不操作，Session 自动失效。
3. 热点数据缓存：缓存数据库查询结果，设置一个较长的过期时间（如1小时），结合“延迟双删”等策略，在更新数据库后主动删除缓存，防止脏数据。
4. 频率限制（限流）：比如限制一个IP地址一分钟内只能请求10次，可以用 key 为 rate_limit:IP地址，用 INCR 命令增加计数，第一次设置时，同时设置过期时间为1分钟，一分钟过后，这个 key 自动消失，计数从零开始。
5. 简单的分布式锁：用 SET key random_value NX PX 30000 尝试获取锁，NX 表示只有 key 不存在时才设置，PX 30000 表示30秒后自动过期释放锁。这里有个巨大陷阱：一定要给锁设置一个合理的过期时间，并且这个时间必须大于你业务逻辑执行的时间，否则锁可能因为超时被自动释放，而另一个客户端又能拿到锁，导致数据错乱，更完善的方案还要用 Lua 脚本保证解锁操作的原子性。

总结一下关键细节：

• 核心矛盾：内存及时回收 vs CPU 性能平稳。
• 关键策略：惰性删除 + 定期删除，理解定期删除的循环机制。
• 重要套路：避免大批量 key 同时过期，给过期时间加随机数。
• 持久化影响：RDB 不存过期 key，AOF 重写时也不存，重启后数据状态一致。
• 实战要点：根据业务场景（验证码、会话、缓存、限流、锁）选择合适的过期时间，并注意相关陷阱（如分布式锁的超时问题）。

把这些套路和细节摸透了,你在用 Redis 过期功能时，就能心里有底，少踩很多坑。