【Redis】Redis 内存淘汰策略

概述

当我们往 Redis 中设置键值对时,有一些键值对会给过期时间,而有一些却不会给,而当设置的键值对的数据超过了给 Redis 设置的最大内存,Redis 就该对这些数据做出淘汰删除数据操作。
在 Redis4.0 之前有六种淘汰机制,Redis4.0 后又加了两种淘汰机制,这八种淘汰机制可分为不进行数据淘汰策略机制和进行数据淘汰策略机制。



数据淘汰策略


不进行数据淘汰策略
  • noeviction: 它是Redis3.0 之后,默认的内存淘汰策略,它表示当运行内存超过最大设置内存时,不淘汰任何数据,这时如果有新的数据写入,则会触发 OOM,但是如果没用数据写入的话,只是单纯的查询或者删除操作的话,还是可以正常工作;

进行数据淘汰策略
在设置了过期时间的数据中进行淘汰
  • volatile-random: 随机淘汰设置了过期时间的任意键值;
  • volatile-ttl: 优先淘汰更早过期的键值;
  • volatile-lru: 它是Redis3.0 之前,默认的内存淘汰策略,淘汰所有设置了过期时间的键值中,最久未使用的键值;
  • volatile-lfu: Redis 4.0 后新增的内存淘汰策略,淘汰所有设置了过期时间的键值中,最少使用的键值;
在所有数据范围内进行淘汰
  • allkeys-random: 随机淘汰任意键值;
  • allkeys-lru: 淘汰整个键值中最久未使用的键值;
  • allkeys-lfu Redis 4.0 后新增的内存淘汰策略,淘汰整个键值中最少使用的键值;


查看与配置数据淘汰机制


查看 Redis 的数据淘汰机制

在 Redis 中使用命令就可以查看,命令如下

config get maxmemory-policy

在这里插入图片描述
通过命令就能看到目前使用的是 noeviction 淘汰机制,这个机制是 Redis3.0 之后默认的机制。


修改 Redis 的数据淘汰机制
方法一

通过 config set maxmemory-policy <策略> 命令设置,它的优点是设置之后立即生效,不需要重启 Redis 服务,缺点是重启 Redis 之后,设置就会失效。

方法二

通过修改 Redis 配置文件修改,设置 maxmemory-policy <策略>,它的优点是重启 Redis 服务后配置不会丢失,缺点是必须重启 Redis 服务,设置才能生效。

在这里插入图片描述



浅谈 LRU 算法和 LFU 算法

LRU 算法

传统 LRU 算法的实现是基于链表结构,链表中的元素按照操作顺序从前往后排列,最新操作的键会被移动到表头,当需要内存淘汰时,只需要删除链表尾部的元素即可,因为链表尾部的元素就代表最久未被使用的元素,这种算法会带来两个问题:

  1. 需要用链表管理所有的缓存数据,这会带来额外的空间开销;
  2. 当有数据被访问时,需要在链表上把该数据移动到头端,如果有大量数据被访问,就会带来很多链表移动操作,会很耗时,进而会降低缓存性能,因为都把时间放在链表移动上了;

而 Redis 的 LRU 算法实现的是一种近似 LRU 算法,目的是为了更好的节约内存,它的实现方式是在 Redis 的对象结构体中添加一个额外的字段,用于记录此数据的最后一次访问时间,当 Redis 进行内存淘汰时,会使用随机采样的方式来淘汰数据,它是随机取 5 个值(此值可配置),然后淘汰最久没有使用的那个,这种方法带来的优点有两个:

  1. 不用为所有的数据维护一个大链表,节省了空间占用;
  2. 不用在每次数据访问时都移动链表项,提升了缓存的性能;

但是缺点也有,就是无法解决缓存污染问题,比如应用一次读取了大量的数据,而这些数据只会被读取这一次,那么这些数据会留存在 Redis 缓存中很长一段时间,造成缓存污染。


LFU 算法

LFU 算法是根据数据访问次数来淘汰数据的,它的核心思想是如果数据过去被访问多次,那么将来被访问的频率也更高
所以, LFU 算法会记录每个数据的访问次数。当一个数据被再次访问时,就会增加该数据的访问次数。这样就解决了偶尔被访问一次之后,数据留存在缓存中很长一段时间的问题,相比于 LRU 算法也更合理一些。
在 LRU 算法中,Redis 对象头中,会有 24 bits 的 lru 字段用来记录 key 的访问时间戳,因此在 LRU 模式下,Redis 可以根据对象头中的 lru 字段记录的值,来比较最后一次 key 的访问时间长,从而淘汰最久未被使用的 key。
在 LFU 算法中,Redis对象头的 24 bits 的 lru 字段 被分成两段来存储:

  • 高 16bit 存储 ldt(Last Decrement Time),用于记录 key 的访问时间戳;
  • 低 8bit 存储 logc(Logistic Counter),用于记录 key 的访问频次,每个新加入的 key 的 logc 初始值为 5;

在这里插入图片描述

注意,logc 并不是单纯的访问次数,而是访问频次(访问频率),因为 logc 会随时间推移而衰减的。
在每次 key 被访问时,会先对 logc 做一个衰减操作,衰减的值跟前后访问时间的差距有关系,如果上一次访问的时间与这一次访问的时间差距很大,那么衰减的值就越大,这样实现的 LFU 算法是根据访问频率来淘汰数据的,而不只是访问次数。访问频率需要考虑 key 的访问是多长时间段内发生的。key 的先前访问距离当前时间越长,那么这个 key 的访问频率相应地也就会降低,这样被淘汰的概率也会更大。
对 logc 做完衰减操作后,就开始对 logc 进行增加操作,增加操作并不是单纯的 + 1,而是根据概率增加,如果 logc 越大的 key,它的 logc 就越难再增加。
所以,Redis 在访问 key 时,对于 logc 是这样变化的:

  1. 先按照上次访问距离当前的时长,来对 logc 进行衰减;
  2. 然后,再按照一定概率增加 logc 的值;

redis.conf 提供了两个配置项,用于 调整 LFU 算法从而控制 logc 的增长和衰减:

  • lfu-decay-time: 用于调整 logc 的衰减速度,它是一个以分钟为单位的数值,默认值为1,lfu-decay-time 值越大,衰减越慢;
  • lfu-log-factor: 用于调整 logc 的增长速度,lfu-log-factor 值越大,logc 增长越慢;




End


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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值