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和延迟之间的折衷。