Redis key过期策略

冷不防 2021-06-10 20:39 486阅读 0赞

Redis所有的数据结构都可以设置过期时间，到期后，key会被自动删除。

Redis key过期的方式有三种：

*  被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key
 *  主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key
 *  当前已用内存超过maxmemory限定时，触发主动清理策略

### 被动删除 ###

只有key被操作时（如`GET`），Redis才会被动检查该key是否过期，过期就删除，并返回NULL。

这种删除策略对CPU友好，不会在删除上浪费无谓的CPU时间。然而这种策略对内存不友好，一个key已经过期，但是在它被操作之前不会被删除，仍然占据内存空间。如果系统中存在大量的不会被访问的数据，就会造成资源浪费。

### 主动删除 ###

Redis会把有过期时间的key放在一个单独的字典里，默认每100ms检查，是否有过期的key，有过期的key则删除。

这里不是每100ms把所有key检查一次，而是随机抽取检查。典型的方式为，Redis每秒做10次如下的步骤：

1.  随机测试100个设置了过期时间的key
2.  删除所有发现的已过期的key
3.  若删除的key超过25个则重复步骤1

这是一个基于概率的简单算法，基本的假设是抽出的样本能够代表整个key空间，Redis持续清理过期的数据直至将要过期的key的百分比降到了25%以下。这也意味着在任何给定的时刻已经过期但仍占据着内存空间的key的量最多为每秒的写操作量除以4。

除了主动淘汰的频率外，Redis对每次淘汰任务执行的最大时长也有一个限定，这样保证了每次主动淘汰不会过多阻塞应用请求。

当Redis启用主从模式时，只有主结点执行上述这两种过期删除策略。主节点在key到期时，会在AOF文件里增加一条`DEL`指令，同步到所有的从节点，从节点通过执行这条del指令来删除过期的key。

### 主动清理 ###

当Redis实例的内存超过设置的maxmemory时，会根据配置的策略`maxmemory-policy`来对key进行淘汰，可选的淘汰策略有如下几种：

*  noeviction:当内存使用达到阈值的时候，会堵塞所有申请内存的命令，可读，可执行del命令。
 *  volatile-lru:当内存使用达到阈值的时候，会优先淘汰设置了过期时间且最近最少使用的key，未设置过期时间的key不会被淘汰。
 *  volatile-ttl:当内存使用达到阈值的时候，会优先淘汰设置了过期时间且剩余过期时间ttl越小的key。
 *  volatile-random:当内存使用达到阈值的时候，会随机淘汰设置了过期时间key。
 *  allkeys-lru:当内存使用达到阈值的时候，针对所有的key按照最近最少使用原则进行淘汰。
 *  allkeys-random:当内存使用达到阈值的时候，针对所有的key随机进行淘汰。

线上的所有Reids实例默认的淘汰策略为volatile-lru。

上述策略可以在`redis.conf`中配置。

## 其他处理key过期 ##

### 生成RDB文件时 ###

> 执行`SAVE`或`BGSAVE`时，数据库键空间中的过期键不会被保存在RDB文件中。

### 载入RDB文件时 ###

> Master载入RDB时，文件中的未过期的键会被正常载入，过期键则会被忽略。 Slave载入RDB时，文件中的所有键都会被载入，当同步进行时，会和Master保持一致。

### AOF文件写入时 ###

> 数据库键空间的过期键的过期但并未被删除释放的状态会被正常记录到`AOF`文件中，当过期键发生释放删除时，`DEL`也会被同步到`AOF`文件中去。

### 重新生成AOF文件时 ###

> 执行`BGREWRITEAOF`时 ，数据库键中过期的键不会被记录到`AOF`文件中

### 复制 ###

> Master删除过期key之后，会向所有Slave服务器发送一个`DEL`命令，从服务器收到之后，会删除这些key。

> Slave在被动的读取过期键时，不会做出操作，而是继续返回该键，只有当Master发送`DEL`通知来，才会删除过期键，这是统一、中心化的键删除策略，保证主从服务器的数据一致性。

### 读写分离时出现数据不一致 ###

> 由于Slave不会主动删除过期key，对于做了读写分离的业务，有可能导致从库读取到过期的脏数据。

代码如下：（5.0版本，在`db.c`中）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o2OTE4Mzc4Nw_size_16_color_FFFFFF_t_70][]

这是因为key的过期删除依赖于`expireIfNeeded`函数，这个函数在任何访问数据的操作中都会被调用并用来检测客户端访问的数据是否过期。

代码第一行就判断了是否过期，如果未过期，直接返回0。

已过期的情况下，如果当前数据库实例角色是Slave，则不进行key过期的删除操作，直接返回1；如果当前数据库实例角色是Master，则首先更新关于失效主键的统计个数，然后将该主键失效的信息进行广播，最后将该主键从Redis中删除。

如何避免

1.  通过scan命令扫库：
    
    当Redis中的key被scan的时候，相当于访问了该key，同样也会做过期检测，充分发挥Redis惰性删除的策略。这个方法能大大降低了脏数据读取的概率，但缺点也比较明显，会造成一定的数据库压力，谨慎合理使用，否则有可能影响线上业务的效率。
2.  升级Redis到新的版本：![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o2OTE4Mzc4Nw_size_16_color_FFFFFF_t_70 1][]
3.   
    
     
    
    在redis 3.2-rc1版本中，增加了key是否过期以及对主从库的判断，如果key已过期，当前访问的是Master则返回NULL；当前访问的是从库，且执行的是只读命令也返回NULL（老版本从库真实的返回该操作的结果，如果该key过期后主库没有删除）。

–EOF–

永久链接：[https://dylanvivi.github.com/posts/redis-key-expire.html][https_dylanvivi.github.com_posts_redis-key-expire.html]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o2OTE4Mzc4Nw_size_16_color_FFFFFF_t_70]: /images/20210527/7f81edfaa4d34406a02b55477fa1ef73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o2OTE4Mzc4Nw_size_16_color_FFFFFF_t_70 1]: /images/20210527/c515bca9203849dd81d2577f45f97555.png
[https_dylanvivi.github.com_posts_redis-key-expire.html]: https://dylanvivi.github.com/posts/redis-key-expire.html