百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术教程 > 正文

谈谈redis中key的生存时间或过期时间,并说下过期键的删除策略

mhr18 2024-11-28 08:51 17 浏览 0 评论

作为目前非常热门的非关系数据库Redis,程序猿们对它是必须掌握的。我们知道Redis提供了5种存储数据的数据类型有string、list、hash、set、zset。而我们本篇内容就为大家来说下Redis中有关键的时间设置问题及过期键的删除策略。

一、Redis中对键的时间设置操作

我们知道在Redis中通过EXPIRE命令或者PEXPIRE命令,客户端可以以秒或者毫秒精度为数据库中的某个键设置生存时间(Time To Live,TTL),在经过指定的秒数或者毫秒数之后,服务器就会自动删除生存时间为0的键:

127.0.0.1:6379> set key value

OK

127.0.0.1:6379> get key

"value"

127.0.0.1:6379> expire key 5 //设置key存活5s

(integer) 1

127.0.0.1:6379> get key // 5s内获取key

"value"

127.0.0.1:6379> get key

"value"

127.0.0.1:6379> get key //5s后获取key

(nil)

127.0.0.1:6379>

说明:SETEX命令可以在设置一个字符串键的同时为键设置过期时间,因为这个命令是一个类型限定的命令(只能用于字符串键),所以这里不对这个命令进行介绍,但SETEX命令设置过期时间的原理和EXPIRE命令设置过期时间的原理是完全一样的。

与EXPIRE命令和PEXPIRE命令类似,客户端可以通过EXPIREAT命令或PEXPIREAT命令,以秒或者毫秒精度给数据库中的某个键设置过期时间( expire time )。

过期时间是一个UNIX时间戳,当键的过期时间来临时,服务器就会自动从数据库中删除这个键:

127.0.0.1:6379> set key value

OK

127.0.0.1:6379> expire key 1377257300

(integer) 1

127.0.0.1:6379> time

1) "1673525507"

2) "35958"

127.0.0.1:6379> get key //1377257300之前

"value"

127.0.0.1:6379> get key //1377257300之后

(nil)

设置过期时间

Redis有四个不同的命令可以用于设置键的生存时间(键可以存在多久)或过期时间(键什么时候会被删除):

EXPIRE<key> <ttl>命令用于将键key的生存时间设置为ttl秒。

PEXPIRE<key> <ttl>命令用于将键key的生存时间设置为tt1毫秒。

EXPIREAT<key><timestamp>命令用于将键key的过期时间设置为timestamp所指定的秒数时间戳。

PEXPIREAT<key><timestamp>命令用于将键key的过期时间设置为timestamp所指定的毫秒数时间戳。

虽然有多种不同单位和不同形式的设置命令,但实际上EXPIRE、PEXPIRE、EXPIREAT三个命令都是使用PEXPIREAT命令来实现的:无论客户端执行的是以上四个命令中的哪一个,经过转换之后,最终的执行效果都和执行PEXPIREAT命令一样。

首先,EXPIRE命令可以转换成PEXPIRE命令,源码函数如下:

def EXPIRE (key,ttl_in_sec) :

#将TTL从秒转换成毫秒

ttl_in_ms = sec_to_ms (ttl_in_sec)

PEXPIRE ( key, ttl_in_ms)

#接着,PEXPIRE命令又可以转换成PEXPIREAT命令:

def PEXPIRE ( key,ttl_in_ms):

#获取以毫秒计算的当前UNIX时间戳

now_ms = get_current_unix_timestamp_in_ms ()

#当前时间加上 TTL,得出毫秒格式的键过期时间

PEXPIREAT (key , now_ms+ttl_in_ms)

#并且,EXPIREAT命令也可以转换成PEXPIREAT命令:

def EXPIREAT ( key,expire_time_in_sec) :

#将过期时间从秒转换为毫秒

expire_time_in_ms = sec_to_ms (expire_time_in_sec)

PEXPIREAT ( key,expire_time_in_ms)

最终,EXPIRE、PEXPIRE和EXPIREAT三个命令都会转换成PEXPIREAT命令来执行,关系如下图:

保存过期时间

redisDb结构的expires字典保存了数据库中所有键的过期时间,我们称这个字典为过期字典:过期字典的键是一个指针,这个指针指向键空间中的某个键对象(也即是某个数据库键)。

过期字典的值是一个long类型的整数,这个整数保存了键所指向的数据库键的过期时间(一个毫秒精度的UNIX时间戳)。

typedef struct redisDb {

//...

//过期字典,保存着键的过期时间

dict *expires;

//...

}redisDb;

我们使用图片来展示一个带有过期字典的数据库例子。在这个例子当中,键空间保存了数据库中所有的键值对,而过期字典则保存了数据库键的过期时间。

第一个键值对的键为alphabet键对象,值为1385877600000,这表示数据库键alphabet的过期时间为1385877600000 ( 2013年12月1日零时)。

第二个键值对的键为book键对象,值为1388556000000,这表示数据库键book的过期时间为1388556000000 ( 2014年1月1日零时)。

当客户端执行PEXPIREAT命令(或者其他三个会转换成PEXPIREAT命令的命令)为一个数据库键设置过期时间时,服务器会在数据库的过期字典中关联给定的数据库键和过期时间。

举个例子,如果数据库当前的状态如上图所示,那么在服务器执行以下命令之后:

127.0.0.1:6379> PEXPIREAT message 1391234400000

(integer) 1

过期字典将新增一个键值对,其中键为message键对象,而值则为139123440000o( 2014年2月1日零时),如下图所示:

移除过期时间

使用PERSIST命令可以移除一个键的过期时间。

127.0.0.1:6379> set key value

OK

127.0.0.1:6379> expire key 1000

(integer) 1

127.0.0.1:6379> ttl key

(integer) 992

127.0.0.1:6379> persist key

(integer) 1

127.0.0.1:6379> ttl key

(integer) -1

127.0.0.1:6379>

PERSIST命令就是PEXPIREAT命令的反操作:PERSIST命令在过期字典中查找给定的键,并解除键和值(过期时间)在过期字典中的关联。

计算并返回键剩余生存时间

TTL命令以秒为单位返回键的剩余生存时间,而PTTL命令则以毫秒为单位返回键的剩余生存时间:

127.0.0.1:6379> expire key 1000

(integer) 1

127.0.0.1:6379> ttl key

(integer) 997

127.0.0.1:6379> pttl key

(integer) 993434

127.0.0.1:6379>

TTL和 PTTL两个命令都是通过计算键的过期时间和当前时间之间的差来实现的。

举例说明:对于一个过期时间为1385877600000 (2013年12月1日零时)的键alphabet来说,如果当前时间为1383282000000(2013年11月1日零时),那么对键alphabet执行PTTL命令将返回2595600000,这个值是通过用alphabet键的过期时间减去当前时间计算得出的:1385877600000 - 1383282000000 = 2595600000

另一方面,如果当前时间为1383282000000 (2013年11月1日零时),那么对键alphabet执行TTL命令将返回2595600,这个值是通过计算alphabet键的过期时间减去当前时间的差,然后将差值从毫秒转换为秒之后得出的。

过期键的判定

通过过期字典,程序可以用以下步骤检查一个给定键是否过期:

1)检查给定键是否存在于过期字典:如果存在,那么取得键的过期时间。

2)检查当前UNIX时间戳是否大于键的过期时间:如果是的话,那么键已经过期;否则的话,键未过期。

可以用伪代码来描述这一过程:

def is _expired(key) :

#取得键的过期时间

expire_time_in_ms = redisDb.expires.get (key)

#键没有设置过期时间

if expire_time_in_ms is None:

return False

#取得当前时间的 UNIX时间戳

now_ms = get_current_unix_timestamp_in_ms ()

#检查当前时间是否大于键的过期时间

if now_ms > expire_time_in_ms:

#是,键已经过期

return Trueelse:

#否,键未过期return False

举例说明:

对于一个过期时间为1385877600000 (2013年12月1日零时)的键alphabet来说:

如果当前时间为1383282000000 (2013年11月1日零时),那么调用is_expired (alphabet)将返回ralse,因为当前时间小于alphabet键的过期时间。

另一方面,如果当前时间为1385964000000 ( 2013年12月2日零时),那么调用is_expired (alphabet)将返回True,因为当前时间大于alphabet键的过期时间。

二、过期键删除策略

我们知道了数据库键的过期时间都保存在过期字典中,又知道了如何根据过期时间去判断一个键是否过期,现在剩下的问题是:如果一个键过期了,那么它什么时候会被删除呢?

这个问题有三种可能的答案,它们分别代表了三种不同的删除策略:

(1)定时删除:在设置键的过期时间的同时,创建一个定时器( timer ),让定时器在键的过期时间来临时,立即执行对键的删除操作。

(2)惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键;如果没有过期,就返回该键。

(3)定期删除:每隔一段时间,程序就对数据库进行一次检查,删除里面的过期键。至于要删除多少过期键,以及要检查多少个数据库,则由算法决定。

定时删除

定时删除策略对内存是最友好的:通过使用定时器,定时删除策略可以保证过期键会尽可能快地被删除,并释放过期键所占用的内存。

定时删除策略的缺点

它对CPU时间是最不友好的:在过期键比较多的情况下,删除过期键这一行为可能会占用相当一部分CPU时间,在内存不紧张但是CPU时间非常紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响。

例如,如果正有大量的命令请求在等待服务器处理,并且服务器当前不缺少内存,那么服务器应该优先将CPU时间用在处理客户端的命令请求上面,而不是用在删除过期键上面。

除此之外,创建一个定时器需要用到Redis服务器中的时间事件,而当前时间事件的实现方式——无序链表,查找一个事件的时间复杂度为O(N)——并不能高效地处理大量时间事件。

因此,要让服务器创建大量的定时器,从而实现定时删除策略,在现阶段来说并不现实。

惰性删除

惰性删除策略对CPU时间来说是最友好的:程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可的情况下进行,并且删除的目标仅限于当前处理的键,这个策略不会在删除其他无关的过期键上花费任何CPU时间。

惰性删除策略的缺点

它对内存是最不友好的:如果一个键已经过期,而这个键又仍然保留在数据库中,那么只要这个过期键不被删除,它所占用的内存就不会释放。

在使用惰性删除策略时,如果数据库中有非常多的过期键,而这些过期键又恰好没有被访问到的话,那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB),我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存,而服务器却不会自己去释放它们,这对于运行状态非常依赖于内存的Redis服务器来说,肯定不是一个好消息。

举个例子,对于一些和时间有关的数据,比如日志 ( log),在某个时间点之后,对它们的访问就会大大减少,甚至不再访问,如果这类过期数据大量地积压在数据库中,用户以为服务器已经自动将它们删除了,但实际上这些键仍然存在,而且键所占用的内存也没有释放,那么造成的后果肯定是非常严重的。

定期删除

从上面对定时删除和惰性删除的讨论来看,这两种删除方式在单一使用时都有明显的缺陷:定时删除占用太多CPU时间,影响服务器的响应时间和吞吐量。

惰性删除浪费太多内存,有内存泄漏的危险。

定期删除策略是前两种策略的一种整合和折中:

定期删除策略每隔一段时间执行一次删除过期键操作,并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。

除此之外,通过定期删除过期键,定期删除策略有效地减少了因为过期键而带来的内存浪费。

定期删除策略的难点是确定删除操作执行的时长和频率:

如果删除操作执行得太频繁,或者执行的时间太长,定期删除策略就会退化成定时删除策略,以至于将CPU时间过多地消耗在删除过期键上面。

如果删除操作执行得太少,或者执行的时间太短,定期删除策略又会和惰性删除策略一样,出现浪费内存的情况。

因此,如果采用定期删除策略的话,服务器必须根据情况,合理地设置删除操作的执行时长和执行频率。

惰性删除策略实现

过期键的惰性删除策略由db.c/expireIfNeeded函数实现,所有读写数据库的Redis命令在执行之前都会调expireIfNeeded 函数对输人键进行检查:

如果输入键已经过期,那么expireIfNeeded 函数将输人键从数据库中删除。

如果输入键未过期,那么expireIfNeeded 函数不做动作。

expireIfNeeded函数就像一个过滤器,它可以在命令真正执行之前,过滤掉过期的输入键,从而避免命令接触到过期键。

expireIfNeeded函数执行过程图解:

另外,因为每个被访问的键都可能因为过期而被expireIfNeeded函数删除,所以每个命令的实现函数都必须能同时处理键存在以及键不存在这两种情况:

(1)当键存在时,命令按照键存在的情况执行。

(2)当键不存在或者键因为过期而被expireIfNeeded函数删除时,命令按照键不存在的情况执行。

举例说明,GET命令的执行过程,在这个执行过程中,命令需要判断键是否存在以及键是否过期,然后根据判断来执行合适的动作。

定期删除策略实现

过期键的定期删除策略由redis.c/activeExpirecycle函数实现,每当Redis的服务器周期性操作redis.c/servercron函数执行时,activeExpirecycle函数就会被调用,它在规定的时间内,分多次遍历服务器中的各个数据库,从数据库的expires字典中随机检查一部分键的过期时间,并删除其中的过期键。

整个过程可以用伪代码描述如下:

#默认每次检查的数据库数量

DEFAULT_DB_NUMBERS = 16

#默认每个数据库检查的键数量

DEFAULT_KEY_NUMBERS = 20

#全局变量,记录检查进度

current_db = 0

def activeExpirecycle ( :

#初始化要检查的数据库数量

#如果服务器的数据库数量比DEFAULT_DB_NUMBERS 要小

#那么以服务器的数据库数量为准

if server.dbnum <DEFAULT_DB_NUMBERS:

db_numbers =server.dbnum

else:

db numbers =DEFAULT_DB_NUMBERS

#遍历各个数据库

for i in range (db_numbers) :

#如果current _db的值等于服务器的数据库数量这表示检查程序已经遍历了服务器的所有数据库一次。将current_db重置为0,开始新的一轮遍历

if current_db == server.dbnum :

current_db - o

#"获取当前要处理的数据库

redisDb = server.db [ current_db]

#将数据库索引增1,指向下一个要处理的数据库current_db +1

#检查数据库键

for j in range (DEFAULT_KEY_NUMBERS):

#如果数据库中没有一个键带有过期时间,那么跳过这个数据库

if redisDb . expires.size ( -= 0: break

#随机获取一个带有过期时间的键

key_with_ttl = redisDb.expires.get_random_keyo)

#检查键是否过期,如果过期就删除它

if is expired (key_with_ttl):

delete_key (key_with_ttl)

#已达到时间上限.停止处理

if reach_time_limit() : return

activeExpirecycle 函数的工作模式可以总结如下:

函数每次运行时,都从一定数量的数据库中取出一定数量的随机键进行检查,并删除其中的过期键。

全局变量current_db 会记录当前activeExpirecycle函数检查的进度,并在下一次activeExpirecycle函数调用时,接着上一次的进度进行处理。

比如说,如果当前activeExpirecycle函数在遍历10号数据库时返回了,那么下次activeExpirecycle函数执行时,将从11号数据库开始查找并删除过期键。随着activeExpirecycle函数的不断执行,服务器中的所有数据库都会被检查一遍,这时函数将current_db变量重置为0,然后再次开始新一轮的检查工作。

总结

本篇文章为大家介绍了下Redis中键的生存时间和过期时间的设置及执行、过期键的删除策略进行了说明。

在三种过期策略中,第一种和第三种为主动删除策略,而第二种则为被动删除策略。在Redis服务器中,实际使用的是惰性删除和定期删除两种策略:通过配合使用这两种删除策略,服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。

相关推荐

【推荐】一个开源免费、AI 驱动的智能数据管理系统,支持多数据库

如果您对源码&技术感兴趣,请点赞+收藏+转发+关注,大家的支持是我分享最大的动力!!!.前言在当今数据驱动的时代,高效、智能地管理数据已成为企业和个人不可或缺的能力。为了满足这一需求,我们推出了这款开...

Pure Storage推出统一数据管理云平台及新闪存阵列

PureStorage公司今日推出企业数据云(EnterpriseDataCloud),称其为组织在混合环境中存储、管理和使用数据方式的全面架构升级。该公司表示,EDC使组织能够在本地、云端和混...

对Java学习的10条建议(对java课程的建议)

不少Java的初学者一开始都是信心满满准备迎接挑战,但是经过一段时间的学习之后,多少都会碰到各种挫败,以下北风网就总结一些对于初学者非常有用的建议,希望能够给他们解决现实中的问题。Java编程的准备:...

SQLShift 重大更新:Oracle→PostgreSQL 存储过程转换功能上线!

官网:https://sqlshift.cn/6月,SQLShift迎来重大版本更新!作为国内首个支持Oracle->OceanBase存储过程智能转换的工具,SQLShift在过去一...

JDK21有没有什么稳定、简单又强势的特性?

佳未阿里云开发者2025年03月05日08:30浙江阿里妹导读这篇文章主要介绍了Java虚拟线程的发展及其在AJDK中的实现和优化。阅前声明:本文介绍的内容基于AJDK21.0.5[1]以及以上...

「松勤软件测试」网站总出现404 bug?总结8个原因,不信解决不了

在进行网站测试的时候,有没有碰到过网站崩溃,打不开,出现404错误等各种现象,如果你碰到了,那么恭喜你,你的网站出问题了,是什么原因导致网站出问题呢,根据松勤软件测试的总结如下:01数据库中的表空间不...

Java面试题及答案最全总结(2025版)

大家好,我是Java面试陪考员最近很多小伙伴在忙着找工作,给大家整理了一份非常全面的Java面试题及答案。涉及的内容非常全面,包含:Spring、MySQL、JVM、Redis、Linux、Sprin...

数据库日常运维工作内容(数据库日常运维 工作内容)

#数据库日常运维工作包括哪些内容?#数据库日常运维工作是一个涵盖多个层面的综合性任务,以下是详细的分类和内容说明:一、数据库运维核心工作监控与告警性能监控:实时监控CPU、内存、I/O、连接数、锁等待...

分布式之系统底层原理(上)(底层分布式技术)

作者:allanpan,腾讯IEG高级后台工程师导言分布式事务是分布式系统必不可少的组成部分,基本上只要实现一个分布式系统就逃不开对分布式事务的支持。本文从分布式事务这个概念切入,尝试对分布式事务...

oracle 死锁了怎么办?kill 进程 直接上干货

1、查看死锁是否存在selectusername,lockwait,status,machine,programfromv$sessionwheresidin(selectsession...

SpringBoot 各种分页查询方式详解(全网最全)

一、分页查询基础概念与原理1.1什么是分页查询分页查询是指将大量数据分割成多个小块(页)进行展示的技术,它是现代Web应用中必不可少的功能。想象一下你去图书馆找书,如果所有书都堆在一张桌子上,你很难...

《战场兄弟》全事件攻略 一般事件合同事件红装及隐藏职业攻略

《战场兄弟》全事件攻略,一般事件合同事件红装及隐藏职业攻略。《战场兄弟》事件奖励,事件条件。《战场兄弟》是OverhypeStudios制作发行的一款由xcom和桌游为灵感来源,以中世纪、低魔奇幻为...

LoadRunner(loadrunner录制不到脚本)

一、核心组件与工作流程LoadRunner性能测试工具-并发测试-正版软件下载-使用教程-价格-官方代理商的架构围绕三大核心组件构建,形成完整测试闭环:VirtualUserGenerator(...

Redis数据类型介绍(redis 数据类型)

介绍Redis支持五种数据类型:String(字符串),Hash(哈希),List(列表),Set(集合)及Zset(sortedset:有序集合)。1、字符串类型概述1.1、数据类型Redis支持...

RMAN备份监控及优化总结(rman备份原理)

今天主要介绍一下如何对RMAN备份监控及优化,这里就不讲rman备份的一些原理了,仅供参考。一、监控RMAN备份1、确定备份源与备份设备的最大速度从磁盘读的速度和磁带写的带度、备份的速度不可能超出这两...

取消回复欢迎 发表评论: