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),是因为文件的更新是需要我们自己去手动告知当前依赖的运行程序:"嘿,哥们!配置文件更新啦,你得重新读一下配置内容!!",我们告知的方式就是向当前运行程序发送一个系统信号,...
-
下一篇
死磕 java同步系列之ReentrantLock VS synchronized——结果可能跟你想的不一样
问题 (1)ReentrantLock有哪些优点? (2)ReentrantLock有哪些缺点? (3)ReentrantLock是否可以完全替代synchronized? 简介 synchronized是Java原生提供的用于在多线程环境中保证同步的关键字,底层是通过修改对象头中的MarkWord来实现的。 ReentrantLock是Java语言层面提供的用于在多线程环境中保证同步的类,底层是通过原子更新状态变量state来实现的。 既然有了synchronized的关键字来保证同步了,为什么还要实现一个ReentrantLock类呢?它们之间有什么异同呢? ReentrantLock VS synchronized 直接上表格:(手机横屏查看更方便) 功能 ReentrantLock synchronized 可重入 支持 支持 非公平 支持(默认) 支持 加锁/解锁方式 需要手动加锁、解锁,一般使用try..finally..保证锁能够释放 手动加锁,无需刻意解锁 按key锁 不支持,比如按用户id加锁 支持,synchronized加锁时需要传入一个对象 公平锁 支持,new...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- 2048小游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2更换Tomcat为Jetty,小型站点的福音