Redis内存策略：「过期Key删除策略」+ 「内存淘汰策略」-编程知识

Redis之所以性能强，最主要的原因就是基于内存存储，然而单节点的Redis其内存大小不宜过大，否则会影响持久化或主从同步的性能。

Redis内存满了，会发生什么？

在Redis的运行内存达到了某个阈值，就会触发内存淘汰机制，这个阈值就是我们设置的最大运行内存。

我们可以通过修改redis.conf配置文件来设置Redis的最大内存，配置项为maxmemory：

# 格式：
# maxmemory <bytes>
# 例如：
maxmemory 1gb

当内存使用达到上限，就无法存储更多数据了，因此，为了解决这个问题，Redis内部会有两套内存回收的策略：

内存过期策略
内存淘汰策略

内存过期策略 - 过期key处理 - 过期删除策略

如何设置过期时间？

expire key n秒
pexpire key n毫秒
set key value ex n秒
set key value nx n毫秒

查看某个key剩余的存活时间：TTL key

我们可以通过expire / EX命令给Redis的key设置TTL（过期时间 / 存活时间），单位：秒，当key的TTL到期以后，即当过期时间到了以后，再次访问该key时返回的是nil，说明这个Key已经不存在了，对应的内存也得到释放，从而起到内存回收的目的。

# 写入一条数据
set num 123
# 设置20秒过期时间
expire num 20
# 写入一条数据并设置20s过期时间
set num EX 20

Redis是如何知道一个key是否过期呢？

Redis本身是一个典型的key-value的键值型内存存储数据库，因此所有的key-value都保存在Dict结构中，在其redisDb结构体中，有两个Dict，也就是哈希表：一个用来记录KEY-VALUE键值对（当然存的不是真正的Key-Value，存储的其实是RedisObject对应的内存地址的指针），另一个用来记录key的TTL。

过期字典存储在 redisDb 结构中，如下：

来看下redisDb的底层源码：

typedef struct redisDb {dict dict;                 / The keyspace for this DB , 也就是存放KEY和VALUE的哈希表*/dict *expires;              /* 同样是哈希表，但保存的是设置了TTL的KEY，及其到期时间*/dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP)*/dict *ready_keys;           /* Blocked keys that received a PUSH */dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS /int id;                     / Database ID, 0 ~ 15 /long long avg_ttl;          / Average TTL, just for stats /unsigned long expires_cursor; / Cursor of the active expire cycle. */list *defrag_later;         /* List of key names to attempt to defrag one by one, gradually. */
} redisDb;

每当我们对一个key设置了过期时间后，Redis会把该key带上过期时间存储到一个过期字典(expires dict)中，也就是说「过期字典」保存了数据库中所有 key 的过期时间。

当我们查询一个 key 时，Redis 首先检查该 key 是否存在于过期字典中：

如果不在，则正常读取键值；
如果存在，则会获取该 key 的过期时间，然后与当前系统时间进行比对，如果比系统时间大，那就没有过期，否则判定该 key 已过期 => 查询到对应的TTL，加以判断即可。

是不是TTL到期就立即删除了呢？

TTL（Time To Live）的含义是存活时间。

Redis并不会在Key过期时立刻删除KEY，因为要实现这样的效果就必须给每一个过期Key设置一个定时器，并监控这些Key的过期状态，然后去做判断，在key过期的那一刻给它立刻删掉 => 定时删除，它的优点就是保证过期key会被尽快删除，也就是内存可以尽快得到释放，因此，定时删除对内存是最友好的；
如果说我们的key比较少那还好，但是如果我们的key非常的多，达到数十万甚至数百万，那么这些key如果我们都给它设置这样一个定时器，无论是对CPU还是对内存都会带来极大的负担，这样一来，就会严重影响到Redis服务本身的一个性能，所以说这个是没有办法接受的，因此，我们在实际应用当中，Redis采用的并不是立即删除，而是惰性删除 + 周期删除 => Redis 使用的过期删除策略是「惰性删除+定期删除」这两种策略配和使用。

Redis的过期KEY删除策略有两种：

惰性删除
周期删除或定期删除

惰性删除

顾名思义就是TTL过期后不会立刻删除，惰性删除策略的做法是，不主动删除过期键，而是在访问使用一个key的时候，判断当前key有没有设置TTL过期时间，如果有，则检查该key的存活时间，如果发现key已经过期才执行删除操作。

惰性删除策略的优缺点：

优点：

因为每次访问时，才会检查该key是否过期，因此惰性删除策略可以节省CPU资源，对CPU时间最友好。

缺点：

如果一个key已经过期，而这个key又仍然保留在数据库中，那么只要这个过期key一致没有被访问，它所占用的内存就不会释放，会造成一定的内存空间浪费，所以惰性删除策略对内存不友好 => 这不就是会导致内存泄漏吗？？？

周期删除 / 定期删除策略

顾名思义就是通过一个定时任务，每隔一段时间周期性的从数据库中抽取一定数量的key进行检查，并删除其中的过期key。

Redis默认会每秒进行10次过期检查（此配置可以通过Redis的配置文件redis.conf进行配置，配置键为hz，它的默认值是hz 10），每次检查数据库并不是遍历过期字典中的所有key，而是从数据库中随机抽取一定数量的key进行过期检查：

从过期字典中随机抽取20个key；
检查这20个key是否过期，并删除已过期的key；
如果本轮检查的已过期key的数量，超过5个（5 / 20 = 1 / 4 = 25%），也就是「已过期 key 的数量」占比「随机抽取 key 的数量」大于 25%，则继续随机抽查，重复步骤1；如果已过期的key的比例小于25%，则停止继续删除过期key，退出本轮检查，然后等待下一轮再检查。

可以看到，定期删除是一个循环的流程。

Redis为了保证定期删除不会出现循环过度，导致线程卡死现象，为此增加了定期删除循环流程的时间上限，默认不会超过25ms，超出时间限制则退出。

定期删除策略的优缺点

优点：

定期删除是Redis的主动删除策略，它可以确保过期key能够及时被删除

缺点：

会占用CPU资源去扫描key，可能会影响到Redis的性能

可以看到，惰性删除策略和定期删除策略都有各自的优缺点，所以Redis选择「惰性删除+定期删除」这两种策略配和使用，以求在合理使用 CPU 时间和避免内存浪费之间取得平衡。

如果过期键没有被访问，而定期删除又跟不上新键产生的速度，内存不就慢慢耗尽了吗？

内存淘汰策略

内存淘汰：

就是当Redis的内存使用达到设置的阈值时，Redis就会主动挑选部分key删除以释放更多内存的流程，这就叫做内存淘汰机制。

内存淘汰时机

当内存达到阈值时执行内存淘汰，但问题是Redis什么时候会去判断内存是否达到阈值呢？

Redis每次执行任何命令时，都会判断内存是否达到阈值。

当Redis内存不足时会怎么做？

这取决于配置的内存淘汰策略，Redis支持很多种内存淘汰策略，例如LRU、LFU、Random，但默认的策略是直接决绝新的写入请求，而如果设置了其它策略，则会在每次执行命令后判断内存占用是否达到阈值，如果达到阈值则会基于配置的内存淘汰策略尝试进行内存淘汰，直到占用内存小于阈值为止。

Redis 内存淘汰策略有哪些？

Redis支持内存淘汰，配置参数maxmemory_policy决定了内存淘汰策略，这个参数一共有8个枚举值，也就是说Redis内存淘汰策略共有8种，这八种策略大体分为「不进行数据淘汰」和「进行数据淘汰」两类策略：

1. 不进行数据淘汰的策略

noeviction（Redis3.0之后，默认的内存淘汰策略）：禁止删除数据，它表示当Redis的运行内存超过最大设置内存时，也就是当Redis内存满时，不淘汰任何键值对数据，而是不再提供服务，不允许写入新数据，Redis的写命令会直接返回错误信息（但是读命令还是可以正常返回）。

2. 进行数据淘汰的策略

针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略。在设置了过期时间的数据中进行淘汰：

volatile-random：随机淘汰设置了过期时间的任意键值 - 从已设置过期时间的数据集中任意选择数据淘汰；
volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰：比较key的剩余TTL值，TTL越小越先被淘汰。
volatile-lru（Redis3.0 之前，默认的内存淘汰策略）：LRU（Least Recently Used），最近最久未使用，利用LRU算法淘汰所有设置了TTL过期时间的键值中，最久未使用的键值；
volatile-lfu（Redis 4.0 后新增的内存淘汰策略）：LFU（Least Frequently Used），最少频率使用，淘汰所有设置了TTL过期时间的键值中，最少使用的键值；

在所有数据范围内进行淘汰：

allkeys-random：对全体key，随机进行淘汰;
allkeys-lru：LRU（Least Recently Used），最近最久未使用，淘汰全体键值中最久未使用的键值；
allkeys-lfu（Redis 4.0 后新增的内存淘汰策略）：：LFU（Least Frequently Used），最少频率使用，淘汰整个键值中最少使用的键值，即访问频率最低的那个key-value。

比较容易混淆的有两个算法：

LRU（Least Recently Used），最近最久未使用（根据访问时间淘汰），会选择淘汰最近最少使用的数据，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
LFU（Least Frequently Used），最少频率使用（根据访问频率淘汰），会统计每个key的访问频率，值越小淘汰优先级越高。

Redis 4.0开始支持基于LFU算法的淘汰策略！

Redis为什么新增了LFU淘汰策略？

为什么Redis 4.0有了LFU？

比如Redis中的一个键，之前一直都没有被访问过，最近突然被访问了一次，如果使用LRU淘汰策略就很难被淘汰，因为LRU会把它定义为热键；
而使用LFU淘汰策略该key就可能很快被淘汰，因为LRU优先淘汰最近未被使用的，而LFU淘汰的是最近访问频率最低的。
LFU比LRU淘汰更精确，有助于提升Redis的缓存命中率。

Redis怎么知道某个KEY的最后一次访问时间或者是访问频率呢？

redisObject结构体当中的lru就是记录最近一次访问时间和访问频率的，以低8位无符号数字来记录逻辑访问次数。
逻辑访问次数又是怎么回事呢？8位无符号数字最大才255，访问次数超过255怎么办？

逻辑访问次数是如何计算的？

由于记录访问次数的只有8bit，即便是无符号数，最大值只有255，不可能记录真实的访问次数，因此LFU的访问次数之所以叫做逻辑访问次数，是因为并不是每次key被访问都计数，Redis统计的其实是逻辑访问次数，这其中是一个计算公式，会根据当前的访问次数做计算，结果要么是次数 + 1，要么是次数不变，且最大不超过255，除此以外，逻辑访问次数还有一个衰减周期，访问次数会随时间衰减，默认为1分钟，即每隔1分钟逻辑访问次数会 -1，这样逻辑访问次数就能基本反映出一个key的访问热度了。

显然LFU的基于访问频率的统计更符合我们的淘汰目标，因此官方推荐使用LFU算法。

内存淘汰用到的是LRU算法吗？

嗯...Redis使用的是近似LRU算法，传统LRU算法的实现需要一个双向链表来记录数据最近被访问的顺序，最新操作的键会被移动到表头，当需要内存淘汰时，只需要删除链表尾部的数据即可，因为链表尾部的元素就代表最久未被使用的元素。
但是Redis中的KEY可能有数百万甚至更多，出于节省内存的考虑，Redis的LRU算法并非完整的实现，Redis的算法并不是真正的LRU，而是一种基于抽样的近似LRU算法！
Redis采用的是抽样法，即每次抽样一定数量（maxmemory-samples）的key，然后和目前维持的淘汰候选池综合比较，然后基于内存策略做排序，找出淘汰优先级最高的，删除这个key，这就使得算法的结果更接近于真正的LRU算法了，特别是在抽样值较高的情况下（例如10），可以达到与真正的LRU接近的结果。

当Redis作为缓存使用的时候，推荐使用allkeys-lru淘汰策略，该策略会将最近最久未使用的key淘汰，像这种key后期命中的概率也最低，所以将其淘汰。