Redis进阶 - 朝生暮死之Redis过期策略

news2024/11/29 0:38:55

在这里插入图片描述

概述

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
OK

127.0.0.1:6379> ttl s
(integer) 5

127.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），在某个时间点之后，对它们的访问就会大大减少，如果大量的这些过期数据积压在数据库里面，用户以为它们已经过期了（已经被删除了），但实际上这些键却没有真正的被删除（内存也没有被释放），那结果肯定是非常糟糕。