本文主要是介绍Redis进阶 - 朝生暮死之Redis过期策略，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
概述
Redis 是一种常用的内存数据库，其所有的数据结构都可以设置过期时间，时间一到，就会自动删除。你可以想象 Redis 内部有一个死神，时刻盯着所有设置了过期时间的 key，寿命一到就会立即收割。
你还可以进一步站在死神的角度思考，会不会因为同一时间太多的 key 过期，以至于忙不过来。同时因为 Redis 是单线程的，收割的时间也会占用线程的处理时间，如果收割的太过于繁忙，会不会导致线上读写指令出现卡顿。所有在过期这件事上，Redis 非常小心。
一、Redis 数据过期
1.1 Redis中key的过期时间
通过 EXPIRE key seconds 命令来设置数据的过期时间。返回1表明设置成功，返回0表明key不存在或者不能成功设置过期时间。在key上设置了过期时间后key将在指定的秒数后被自动删除。
127.0.0.1:6379> SETEX key 5 value
OK127.0.0.1:6379> ttl s
(integer) 5127.0.0.1:6379> GET key
"value"127.0.0.1:6379> GET key ## 5 秒过后
(nil)
命令 TTL 用于返回给定键距离过期还有多长时间。注意：当key被DEL命令删除或者被SET、GETSET命令重置后与之关联的过期时间会被清除。
Redis 有四个命令可以设置键的生存时间（可以存活多久）和过期时间（什么时候到期），如下表所示：
| 命令 | 说明 |
|---|---|
| expire key seconds | 以秒为单位设置键的生存时间 |
| pexpire key milliseconds | 以毫秒为单位设置键的生存时间 |
| expireat key timestamp | 以秒为单位，设置键的过期 UNIX 时间戳 |
| pexpireat key milliseconds-timestamp | 以毫秒为单位，设置键的过期 UNIX 时间戳 |
1.2 基于时间的过期策略
-
在Redis中，可以使用EXPIRE和PEXPIRE命令为键设置生存时间，以秒或毫秒为单位。例如：
# 设置多少秒后过期 EXPIRE key seconds # 设置多少毫秒后过期 PEXPIRE key milliseconds # 设置 key 过期时间的时间戳(unix timestamp) 以秒计 EXPIREAT key timestamp # 设置 key 过期时间的时间戳(unix timestamp) 以毫秒计 PEXPIREAT key milliseconds-timestamp -
可以使用TTL命令或PTTL命令来查看键的剩余生存时间（以秒或毫秒为单位）。例如：
# 以秒为单位，返回给定 key 的剩余生存时间 TTL key # 以毫秒为单位返回 key 的剩余的过期时间 PTTL key -
可以使用PERSIST命令来取消键的生存时间，使其永久保存。例如：
# 移除key的过期时间，key将保持永久 PERSIST key
二、Redis数据过期策略
Redis的过期策略主要是通过定时删除、惰性删除和定期删除三种方式来管理键的生命周期。
| 过期策略 | 说明 |
|---|---|
| 定时删除 | 为每个设置了过期时间的键创建一个定时器，一旦过期就立即删除。 但是这种方式可能会消耗大量的CPU资源，因此Redis默认不使用这种策略。 |
| 定期删除 | 每隔一段时间随机抽查一些键，删除其中已经过期的键。 这种方式是前两种方式的折衷，结合了定时任务和惰性删除的优点，是Redis默认采用的策略。 |
| 惰性删除 | 只有在访问键时，才会检查键是否过期，过期则删除。 这种方式可以最大程度地节省CPU资源，但可能会导致大量的空间浪费。 |
2.1 定时删除
Redis 在设置键的过期时间时，创建一个定时事件，当过期时间到达时，由事件处理器自动执行键的删除操作。定时删除策略对内存是最友好的，因为它保证过期键会在第一时间被删除， 过期键所消耗的内存会立即被释放。但它对 CPU 时间是最不友好的，因为删除操作可能会占用大量的 CPU 时间，将 CPU 时间花在删除那些和当前任务无关的过期键上，从而影响缓存的响应时间和吞吐量，这种做法毫无疑问会是低效的，因此Redis默认不使用这种策略。
2.2 定期删除
Redis 的定期删除策略是一种平衡的方法，它定时地检查 Redis 库中的过期数据，采用随机抽样的方法，根据过期数据的比例来调整删除的速度。过期数据的比例是指 Redis 在定期删除策略中，根据每次随机抽样的键中有多少是过期的来决定是否继续删除。如果过期的键比例超过 1/4，就继续抽样和删除。这样可以根据过期数据的密集程度来控制删除的频率，避免过多占用 CPU 资源或内存空间。
Redis 会将每个设置了过期时间的 key 存入到一个单独的字典中，默认每秒进行 10 次过期检查一次数据库。每次检查数据库并不是遍历过期的所有 key，而是从数据库中随机抽取一定数量的 key 进行过期检查。接下来，详细说说 Redis 的定期删除的流程。
此时，会有人问“至于为什么不扫描所有的 key？”，这个问题很简单，Redis 作为一个单线程系统，全面扫描所有键值对可能会大幅度地影响性能。因此，Redis 限制每次过期扫描的最大耗时，这个限制默认是 25ms。如果用户将操作超时设置得太短，比如 10ms，那么许多连接可能会由于超时而关闭，导致应用出现许多异常。此时，Redis 的慢查询日志可能并没有任何记录，因为慢查询记录的只是命令的处理时间，而不包括等待时间。当大量键值对在同一时刻过期时，Redis 会多次扫描过期字典，直到过期键的比例低于四分之一。这可能会导致短暂的系统卡顿，尤其在并发请求高的情况下，这可能引发所谓的缓存雪崩。
2.3 惰性删除
与定期删除不同，懒惰删除策略并不会定时地去扫描和删除过期的键，而是在每次访问 key 时，才会判断该key是否已过期。若是过期则清除，并且删除的目标仅限于当前处理的键；如果没有过期，不做任何处理，然后返回正常的键值对给客户端。如下图所示：
惰性删除对比定期删除而言，可以节省处理器时间，因为只有在键被访问时，Redis 才会去检查并删除过期的键。这种策略在很多情况下都能有效地处理过期的键，因为很多过期的键可能永远都不会被访问，因此没有必要花费时间去删除它们。
然而，惰性删除可能会导致过期的键占用内存空间。因为只有在键被访问时，Redis才会删除它，如果一个过期的键一直没有被访问，那么它就会一直占用内存空间，这在内存紧张的环境下可能会成为一个问题。举个例子， 对于一些按时间点来更新的数据， 比如日志（log）， 在某个时间点之后， 对它们的访问就会大大减少， 如果大量的这些过期数据积压在数据库里面， 用户以为它们已经过期了（已经被删除了）， 但实际上这些键却没有真正的被删除（内存也没有被释放）， 那结果肯定是非常糟糕。
三、结语
Redis 缓存的过期策略是保证缓存可靠性和性能的关键之一，通过设置键值对缓存、设置过期时间、取消过期时间和查看 Redis 内存使用情况等操作，可以实现对缓存的控制和管理。需要注意的是，在设置缓存过期时间时，应根据业务场景和数据类型来选择合适的时间。
这篇关于Redis进阶 - 朝生暮死之Redis过期策略的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
