Redis之过期策略、内存淘汰机制、LRU

Redis之过期策略、内存淘汰机制、LRU

1.Redis的过期策略

Redis的过期策略,是有定期删除+惰性删除两种。
定期好理解,默认100s就随机抽一些设置了过期时间的key,去检查是否过期,过期了就删了。
惰性删除,见名知意,惰性嘛,我不主动删,我懒,我等你来查询了我看看你过期没,过期就删了还不给你返回,没过期该怎么样就怎么样。

对于定期删除来说,为啥不扫描全部设置了过期时间的key呢?

假如Redis里面所有的key都有过期时间,都扫描一遍?那太恐怖了,而且我们线上基本上也都是会设置一定的过期时间的。全扫描跟你去查数据库不带where条件不走索引全表扫描一样,100s一次,Redis累都累死了。

对于定期删除来说,如果一直没随机到很多key,里面不就存在大量的无效key了?或者对于惰性删除来说我也没查询,该如何?

应用到了内存淘汰机制

2.内存淘汰机制

官网上给到的内存淘汰机制是以下几个:
1)noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令(大部分的写入指令,但DEL和几个例外)
2)allkeys-lru: 尝试回收最少使用的键(LRU),使得新添加的数据有空间存放。
3)volatile-lru: 尝试回收最少使用的键(LRU),但仅限于在过期集合的键,使得新添加的数据有空间存放。
4)allkeys-random: 回收随机的键使得新添加的数据有空间存放。
5)volatile-random: 回收随机的键使得新添加的数据有空间存放,但仅限于在过期集合的键。
6)volatile-ttl: 回收在过期集合的键,并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放。
注:如果没有键满足回收的前提条件的话,策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。

3.LRU

至于LRU我也简单提一下,手写实在是太长了,大家可以去Redis官网看看,我把近视LUR效果给大家看看:
tip:Redis为什么不使用真实的LRU实现是因为这需要太多的内存。不过近似的LRU算法对于应用而言应该是等价的。使用真实的LRU算法与近似的算法可以通过下面的图像对比。
你可以看到三种点在图片中, 形成了三种带.
浅灰色带是已经被回收的对象。
灰色带是没有被回收的对象。
绿色带是被添加的对象。
LRU实现的理论中,我们希望的是,在旧键中的第一半将会过期。RedisLRU算法则是概率的过期旧的键。
你可以看到,在都是五个采样的时候Redis 3.0比Redis 2.8要好,Redis2.8中在最后一次访问之间的大多数的对象依然保留着。使用10个采样大小的Redis 3.0的近似值已经非常接近理论的性能。
注意LRU只是个预测键将如何被访问的模型。另外,如果你的数据访问模式非常接近幂定律,大部分的访问将集中在一个键的集合中,LRU的近似算法将处理得很好。

LRU comparison

其实在大家熟悉JAVA中的LinkedHashMap中也实现了Lru算法的,实现如下:
当容量超过100时,开始执行LRU策略:将最近最少未使用的 TimeoutInfoHolder 对象 evict 掉。

真实面试中会让你写LUR算法,你可别搞原始的那个,写不完的,你要么怼上面这个,要么怼下面这个,找一个数据结构实现下Java版本的LRU还是比较容易的,知道啥原理就好了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

GoGo在努力

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值