Redis八大内存淘汰的策略详解

Redis的数据已经设置了TTL,不是过期就已经删除了吗?为什么还存在所谓的淘汰策略呢?这个原因我们需要从redis的过期策略聊起。

过期策略

定期删除

redis 会将每个设置了过期时间的 key 放入到一个独立的字典中,以后会定期遍历这个字典来删除到期的 key。

Redis 默认会每秒进行十次过期扫描(100ms一次),过期扫描不会遍历过期字典中所有的 key,而是采用了一种简单的贪心策略。

1.从过期字典中随机 20 个 key;

2.删除这 20 个 key 中已经过期的 key;

3.如果过期的 key 比率超过 1/4,那就重复步骤 1;

redis默认是每隔 100ms就随机抽取一些设置了过期时间的key,检查其是否过期,如果过期就删除。注意这里是随机抽取的。为什么要随机呢?你想一想假如 redis 存了几十万个 key ,每隔100ms就遍历所有的设置过期时间的 key 的话,就会给 CPU 带来很大的负载。

惰性删除

所谓惰性策略就是在客户端访问这个key的时候,redis对key的过期时间进行检查,如果过期了就立即删除,不会给你返回任何东西。

定期删除可能会导致很多过期key到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key,靠定期删除没有被删除掉,还停留在内存里,除非你的系统去查一下那个 key,才会被redis给删除掉。这就是所谓的惰性删除,即当你主动去查过期的key时,如果发现key过期了,就立即进行删除,不返回任何东西.

总结:定期删除是集中处理,惰性删除是零散处理。

为什么需要淘汰策略

有了以上过期策略的说明后,就很容易理解为什么需要淘汰策略了,因为不管是定期采样删除还是惰性删除都不是一种完全精准的删除,就还是会存在key没有被删除掉的场景,所以就需要内存淘汰策略进行补充。

Redis 支持的 淘汰策略

#
# volatile-lru -> Evict using approximated LRU, only keys with an expire set.
# 加入键的时候如果过限,首先从设置了过期时间的键集合中驱逐最久没有使用的键

# allkeys-lru -> Evict any key using approximated LRU.
# 加入键的时候,如果过限,首先通过LRU算法驱逐最久没有使用的键

# volatile-lfu -> Evict using approximated LFU, only keys with an expire set.
# 从所有配置了过期时间的键中驱逐使用频率最少的键

# allkeys-lfu -> Evict any key using approximated LFU.
# 从所有键中驱逐使用频率最少的键

# volatile-random -> Remove a random key having an expire set.
# 加入键的时候如果过限,从过期键的集合中随机驱逐

# allkeys-random -> Remove a random key, any key.
# 加入键的时候如果过限,从所有key随机删除

# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
# 从配置了过期时间的键中驱逐马上就要过期的键

# noeviction -> Don't evict anything, just return an error on write operations.
# 当内存使用超过配置的时候会返回错误,不会驱逐任何键,默认配置
  • 说明

    • LRU指最近使用最少的设备
    • LFU表示使用频率最低
    • LRU、LFU和volatile ttl都是使用近似随机算法实现的。

    注意:对于上述任何策略,当没有合适的键进行逐出时,Redis将在需要更多内存的写入操作上返回错误。这些命令通常用于创建新键、添加数据或修改现有键。例如:SET、INCR、HSET、LPUSH、SUNIONSTORE、SORT(由于STORE参数),以及EXEC(如果事务包含任何需要内存的命令)。

淘汰策略的配置

默认淘汰策略

maxmemory-policy noeviction

LRU、LFU和最小TTL算法不是精确算法,而是近似算法(为了节省内存),因此可以对其进行调整以提高速度或精度。默认情况下,Redis将检查五个键并选择最近使用最少的键,您可以使用以下配置指令更改样本大小。

默认值为5会产生足够好的结果。10非常接近真实的LRU,但CPU成本更高。3更快,但不是很准确。

maxmemory-samples 5

逐出处理设计为在默认设置下运行良好。

如果写入流量异常大,则可能需要增加此值。降低此值可能会降低延迟,但有被逐出的风险处理有效性0=最小延迟,10=默认值,100=不考虑延迟的过程

maxmemory-eviction-tenacity 10

从Redis 5开始,默认情况下,复制副本将忽略其maxmemory设置(除非在故障切换后升级为master或手动)。这意味着密钥的逐出将由主机处理,在主机端的密钥逐出时将DEL命令发送到复制副本。

此行为可确保主副本和副本保持一致,并且通常是您想要的,但是如果您的副本是可写的,或者您希望副本具有不同的内存设置,并且您确定对副本执行的所有写入都是幂等的,然后,您可以更改此默认设置(但一定要了解您正在做什么)。

请注意,由于复制副本在默认情况下不会退出,因此最终可能会使用比通过maxmemory设置的内存更多的内存(复制副本上的某些缓冲区可能更大,或者数据结构有时可能占用更多内存等等)。因此,请确保监视复制副本,并确保它们有足够的内存,在主副本达到配置的maxmemory设置之前,不会出现真正的内存不足情况。

replica-ignore-maxmemory yes

Redis以两种方式回收过期的密钥:当发现这些密钥过期时进行访问,以及在后台,即所谓的“活动过期密钥”。通过交互方式缓慢地扫描密钥空间,寻找过期的密钥进行回收,这样就可以释放内存中过期的密钥,并且在短时间内再也无法访问这些密钥。

expire循环的默认工作将尝试避免超过10%的过期密钥仍在内存中,并尝试避免消耗超过总内存的25%并增加系统延迟。但是,可以将通常设置为“1”的过期“努力”增加到更大的值,直到值“10”。在其最大值时,系统将使用更多的CPU、更长的周期(技术上可能会引入更多的延迟),并将允许系统中仍然存在的已过期密钥更少。这是内存、CPU和延迟之间的折衷。

active-expire-effort 1

Redis 的更多学习资料 可以参考 https://github.com/yanghaiji/Advanced-books

  • 4
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 5
    评论
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

小杨同学~

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

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

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

打赏作者

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

抵扣说明:

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

余额充值