Redis LRU

一：Redis内存驱逐的几种策略

检测易失数据（可能会过期的数据集server.db[i].expires ）

① volatile-lru：挑选最近最少使用的数据淘汰

② volatile-lfu：挑选最近使用次数最少的数据淘汰

③ volatile-ttl：挑选将要过期的数据淘汰

④ volatile-random：任意选择数据淘汰

检测全库数据（所有数据集server.db[i].dict ）

⑤ allkeys-lru：挑选最近最少使用的数据淘汰

⑥ allkeys-lfu：挑选最近使用次数最少的数据淘汰

⑦ allkeys-random：任意选择数据淘汰

放弃数据驱逐

⑧ no-enviction（驱逐）：禁止驱逐数据（ redis4.0中默认策略），会引发错误OOM（ Out Of Memory）

二：传统的LRU算法

采用map+双向链表实现。

​

LRU 算法的设计原则是：如果一个数据在最近一段时间没有被访问到，那么在将来它被访问的可能性也很小。也就是说，当限定的空间已存满数据时，应当把最久没有被访问到的数据淘汰。

 

传统的lru算法是强制移除头部元素，头部元素表示最早插入并且最长时间没有使用，数据之间有严格的边界，数据分布如下图：

绿色：新加入的数据

深灰色：未删除的数据

浅灰色：已经删除的数据

​

• 图 1

三：Redis中的LRU

首先redis并没有使用传统的lru算法进行内存驱逐，是因为传统的lru算法需要额外的双向链表，链表本身需要记录key，还要有前指针和后指针，链表中的引用和指针和key占据的内存在链表长度过大的时候是非常恐怖的（链表的数据空间的占据甚至有可能超过数据本身！），并且这个链表如果应用在redis，可是redis服务全局的链表，链表长度可想而知，redis是基于内存的数据库，内存是宝贵的资源，为了尽可能的降低内存的使用，作者在redis实现中自己去实现了lru算法，舍弃掉了传统lru中的双向链表，但是这个lru并不是很严格，是有可能移除新插入的数据的，redis不同版本中的lru算法实现逻辑还不一样，我们分版本去讲解。

1) Redis 2.8版本中的LRU

简单说一下2.8版本中的lru实现

redis有一个24位的全局时钟，该全局时钟每一段时间会更新，每次在redis中存储/使用数据都会更新redis服务器的当前时钟至该数据，当需要内存驱逐的时候，获得当前服务器的时钟，随机抽取maxmemory-samples设置的n条数据，然后从中找到一个距离当前服务器时间戳差距最大的key，就是需要淘汰的key

图2中 5 samples为参数设置maxmemory-samples：5，刚插入的数据有可能被删除掉，所以，作者在3.0版本中又对lru做了些优化。

绿色：新加入的数据

深灰色：未删除的数据

浅灰色：已经删除的数据

​

2) Redis 3.0版本中的LRU

3.0版本内部维护了一个pool（大小为16），pool中的key的时钟是有序的，接下来只有小于（更早）第一个的时钟的key才能放进去，等pool满了，再次放入的时候会把最大的拿出来，该次的放进去，这样pool中维护的数据都是更加长久没有访问的，时钟更小的，等待需要逐出的时候，把pool中时钟最小的淘汰，该pool其实就是一个局部lru池。

数据分布如下图，边界相比2.8版本的较为清晰，但是相比传统lru，还是有一定差距，但是很大程度上减少了刚插入数据的淘汰。

绿色：新加入的数据

深灰色：未删除的数据

浅灰色：已经删除的数据

​