Redis从入门到放弃系列(七) 过期、内存淘汰策略
Redis从入门到放弃系列(七) 过期、内存淘汰策略
本文例子基于:5.0.4
过期策略
Redis对于设置了过期时间的key的过期策略有两种
- 惰性删除
- 定时随机删除
惰性删除
惰性删除的时机在于当你要获取该key的时候再去做判断.这里我以String类型作为演示画图:
int expireIfNeeded(redisDb *db, robj *key) { if (!keyIsExpired(db,key)) return 0; /* If we are running in the context of a slave, instead of * evicting the expired key from the database, we return ASAP: * the slave key expiration is controlled by the master that will * send us synthesized DEL operations for expired keys. * * Still we try to return the right information to the caller, * that is, 0 if we think the key should be still valid, 1 if * we think the key is expired at this time. */ if (server.masterhost != NULL) return 1; /* Delete the key */ server.stat_expiredkeys++; propagateExpire(db,key,server.lazyfree_lazy_expire); notifyKeyspaceEvent(NOTIFY_EXPIRED, "expired",key,db->id); return server.lazyfree_lazy_expire ? dbAsyncDelete(db,key) : dbSyncDelete(db,key); }
我们发现,当key有设置了过期时间,然后key已经过期的话,那么redis会判断是否开启了lazyfree_lazy_expire
,如果开启的话,那么异步删除.没有则同步直接删除.(4.0之后的特性,当大key删除的时候非常有用)
定时随机删除
当有了惰性删除之后,满足了一部分的需求,可是在实际应用中,会存在有过期而没有被访问到的key,这样就会平白的占据着内存.那么redis是通过怎样去解决的呢?
redis会有一个定时任务,每秒跑10次。
- 随机选择设置了过期时间的20个key进行过期检测
- 删除所有已经过期的keys
- 如果超过25%的密钥过期,请从步骤1重新开始。
由于redis是单线程,如果任由上面定时随机删除策略的话,那么当有大量的key过期的时候,redis会存在无法处理客户端请求的情况?不不不,其实redis在做定时随机删除的时候,有一个限制,就是设置扫描时间的上限,默认至多为25ms(timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;),所以当客户端请求到来时,服务器正处于过期扫描期间,客户端会等到至多25ms然后进行其业务处理.
那么如果redis设置超时时间过短的话,有可能出现大量超时连接,为了避免这个问题,建议是在设置过期时间是时候,加多一个随机范围,避免大量的key同时过期~
当有做主从的时候,从库是不会开启定时随机删除的,都是依赖master开启的aof文件中增加一条del命令,然后从库去执行该语句实现删除该过期key
内存淘汰策略
我们知道redis是纯内存数据库,如果redis使用超出了内存限制的时候,便会产生swap行为. 使用磁盘来操作相比内存来说,性能下降的不是一丁半点。 这时候我们需要设置redis最大使用内存
maxmemory <bytes>
通过设置maxmemory,当使用内存超过maxmemory的时候,redis提供了几种可选的策略来控制内存的使用量
- noeviction (当内存不足以容纳新写入数据时,新写入操作会报错)
- allkeys-lru (当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的key)
- allkeys-random (当内存不足以容纳新写入数据时,在键空间中,随机移除某个key)
- volatile-lru (当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的key)
- volatile-random (当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个key)
- volatile-ttl (当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的key优先移除)
写在最后
端午三天就这样过去啦~愿各位看官好好休息,然后继续起来搬砖~hhhhh

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Go配置文件热加载 - 发送系统信号
在日常项目的开发中,我们经常会使用配置文件来保存项目的基本元数据,配置文件的类型有很多,如:JSON、xml、yaml、甚至可能是个纯文本格式的文件。不管是什么类型的配置数据,在某些场景下,我们可会有热更新当前配置文件内容的需求,比如:使用Go运行的一个常驻进程,运行了一个 Web Server 服务进程。 此时,如果配置文件发生变化,我们如何让当前程序重新读取新的配置文件内容呢?接下来,我们将使用如下两种方式实现配置文件的更新: 使用系统信号(手动式)。 使用inotify, 监听文件修改事件。 不管是哪一种方式,都会用到Go语言中 goroutine 的概念,我打算使用 goroutine 新起一个协程,新协程的目的是用来接收系统信号(signal)或者监听文件被修改的事件,如果你对 goroutine 的概念不是很了解,那么建议你先查阅相关资料。 手动式,使用系统信号。 我之所以称这种方式为手动式(Manual),是因为文件的更新是需要我们自己去手动告知当前依赖的运行程序:"嘿,哥们!配置文件更新啦,你得重新读一下配置内容!!",我们告知的方式就是向当前运行程序发送一个系统信号,...
- 下一篇
Spring Boot 配置文件中的花样,看这一篇足矣!
在快速入门一节中,我们轻松的实现了一个简单的RESTful API应用,体验了一下Spring Boot给我们带来的诸多优点,我们用非常少的代码量就成功的实现了一个Web应用,这是传统的Spring应用无法办到的,虽然我们在实现Controller时用到的代码是一样的,但是在配置方面,相信大家也注意到了,在上面的例子中,除了Maven的配置之后,就没有引入任何的配置。 这就是之前我们所提到的,Spring Boot针对我们常用的开发场景提供了一系列自动化配置来减少原本复杂而又几乎很少改动的模板化配置内容。但是,我们还是需要去了解如何在Spring Boot中修改这些自动化的配置内容,以应对一些特殊的场景需求,比如:我们在同一台主机上需要启动多个基于Spring Boot的web应用,若我们不为每个应用指定特别的端口号,那么默认的8080端口必将导致冲突。 如果您还有在读我的Spring Cloud系列教程,其实有大量的工作都会是针对配置文件的。所以我们有必要深入的了解一些关于Spring Boot中的配置文件的知识,比如:它的配置方式、如何实现多环境配置,配置信息的加载顺序等。 配置基...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Red5直播服务器,属于Java语言的直播服务器
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程