redis，开门！什么是内存淘汰策略啊？

拼搏现实的明天。 2022-10-29 06:29 74阅读 0赞

我：reids 我遇到问题了！

redis：

![在这里插入图片描述][20210210101735705.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]  
如下：

`如果一个键是过期的，那它到了过期时间之后是不是马上就从内存中被被删除呢?`

redis：不是哦！

其实有三种不同的过期删除策略

## 定时删除 ##

`操作`：设置一个定时器 比如1天 一天后把这个key给删除掉

`优点`：可以保证过期的键被立刻删除，内存就会被释放掉了，看起来很好。

`缺点`：但是 **CPU** 的压力就大了 ，如果cpu很繁忙，又要执行删除操作 会产生极大的性能消耗。

> 总结：对CPU不友好，用处理器性能换取存储空间（拿时间换空间）

## 惰性删除 ##

`操作`：

数据到达过期时间，不做处理，等下次访问该数据时：

如果未过期，返回数据。

发现已过期，删除即可，返回空。

`优点`：对CPU的压力小很多 不用频繁的去检查。

`缺点`：它对**内存**是最不友好的，且并不能保证所有过期键都能访问到，可能有些键永远不会被删除，那就会造成内存泄漏。

> 总结：对内存不友好，用存储空间换取处理器性能（拿空间换时间)

## 定期删除 ##

`操作`：每隔一段时间进行检查，删除到了过期时间的 **key**。

`优点`：周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度，有效释放过期的key。

`缺点`：难以确定检查的时间，可能存在一个key过期，但是还没执行删除，业务中又返回了。

> 总结:周期性抽查存储空间（随机抽查，重点抽查)，无法确定删除操作的时长和频率。

redis：没有什么事情是绝对完美的，咱们一般采用的是惰性删除+定期删除相结合的策略，但还是存在某些过期key的大量堆积，那该怎么办呢？

我：redis 你已经长大了，应该自己承担这些责任了。  
![在这里插入图片描述][20210209110747534.png]  
redis：是你自己不会用啊 你看看我的内存淘汰策略！  
![在这里插入图片描述][20210209110835481.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]

我：什么什么！  
![在这里插入图片描述][20210209110909639.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]  
redis: 我就拿最新的版本跟你讲吧 ，现在是redis6.1.10了

给你看看 在redis.conf里面  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]  
知道你英文不好 意思是说

当我内存满的时候 ，你可以选择一种你喜欢的策略，让我进行删除操作。

选择题都不会

这就好比 ，我都躺下了，你也不动一下，还怪我性冷淡。  
![在这里插入图片描述][20210209111619834.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]

我：。。。。。。  
![在这里插入图片描述][45931a12cb4944f6bebe3f5ce22b2f27.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]

redis： 默认我就是**第一种** 满了咱就报错，不删除，要记住哦 ！  
![在这里插入图片描述][20210209111814780.png]  
这8种策略，翻译成中文，就是这个样子。  
![在这里插入图片描述][20210209111735852.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]  
我：这什么lru，lfu是啥啊！

redis：  
LRU是删除最近最少使用的键的一种算法 ，说白了，好久没用的键就会进行删除，强调时间。

LFU是删除最近最不常用的键的一种算法，如果一定时间访问次数最少，那么就会被删除，强调频率。  
![在这里插入图片描述][2021020918330025.png]  
我：脑袋还是懵懵的。。。。。。

redis：经过大佬们的测试 ，最常用的就是`allkeys-lru` ，这是经得起时间考验的策略。

咱们就重点来说说这个策略

比如设置

1.配置文件修改 照猫画虎 改一下就行了  
![在这里插入图片描述][20210209184443291.png]  
2.命令行设置

`config set maxmemory-policy allkeys-lru`

查看也很简单

`config get maxmemory-policy`

在说LRU算法之前

先给你出个题目吧

1 所谓缓存，必须要有读+写两个操作，按照命中率的思路考虑，写操作+读操作时间复杂度都需要为O(1)

2 特性要求分析

必须有顺序之分，以区分最近使用的和很久没用到的数据排序。
    写和读操作 一次搞定。
    如果容量(坑位)满了要删除最不常用的数据，每次新访问还要把新的数据插入到队头(按照业务你自己设定左右那一边是队头)

查找快，插入快，删除快，且还需要先后排序-------->什么样的数据结构满足这个问题?

你是否可以在O(1)时间复杂度内完成这两种操作?

如果一次就可以找到，你觉得什么数据结构最合适?

我：链表插入删除快 还可以排序 但是。。。查找比较慢 ，如果能加上数组就好了，

redis：比较相近了 答案就是 LinkedHashMap ， 双向队列+hashMap， 使得读写都是O(1）。

实现的话，可以使用jdk ，取巧的办法。

public class lruMap<K, V> extends LinkedHashMap<K, V> { 
        private int capacity;
    
        public lruMap(int capacity) { 
            //第三个参数 如果为true 则返回访问顺序的队列 为false 返回插入顺序的队列
            super(capacity, 0.75F, true);
            this.capacity = capacity;
        }
    
        @Override
        protected boolean removeEldestEntry(Map.Entry<K, V> eldest) { 
            //如果返回true 则移除掉最先插入的元素
            return super.size() > capacity;
        }
        public static void main(String[] args) { 
            lruMap<Object, Object> map = new lruMap<>(3);
            map.put(1, 1);
            map.put(2, 1);
            map.put(3, 1);
            System.out.println(map.keySet());
            map.put(4, 1);
            System.out.println(map.keySet());
            //重复插入已有的数据
            map.put(3, 2);
            map.put(3, 2);
            map.put(3, 2);
            System.out.println(map.keySet());
    // 输出结果
    // [1, 2, 3]
    // [2, 3, 4]
    // [2, 4, 3]
        }
    }

将第三个参数改为false

public static void main(String[] args) { 
            lruMap<Object, Object> map = new lruMap<>(3);
            map.put(1, 1);
            map.put(2, 1);
            map.put(3, 1);
            System.out.println(map.keySet());
            map.put(4, 1);
            System.out.println(map.keySet());
            //重复插入已有的数据
            map.put(3, 2);
            map.put(3, 2);
            map.put(3, 2);
            System.out.println(map.keySet());
    // 输出结果 多次插入对队列的顺序不改变
    // [1, 2, 3]
    // [2, 3, 4]
    // [2, 3, 4]
        }

redis：这就是最简易的LRU算法实现 true 和false可以改变读写的队列顺序 快去试试吧

我：ncie！ redis 我还有个问题！

redis：说吧。

我：你怎么还懂jdk啊。。。

redis：

> 你学过的每一样东西，你遭受的每一次苦难，都会在你一生中的、某个时候派上用场。

[20210210101735705.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]: /images/20221024/134b2db1d07649659f3ab1ec796f4ea6.png
[20210209110747534.png]: /images/20221024/44b8cfff1ed94758bec3e9dc879ab6cf.png
[20210209110835481.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]: /images/20221024/4135ad254f2a405480bd298a01e5221b.png
[20210209110909639.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]: /images/20221024/8d5bda971f68434a9a9819e9b8939418.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]: /images/20221024/0869cc36fa4f4eefadf9b41e6e6f3fd0.png
[20210209111619834.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]: /images/20221024/6105482128c348b69bdd4a97abb58355.png
[45931a12cb4944f6bebe3f5ce22b2f27.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]: /images/20221024/93c60bf340164da2a44493b0448e0900.png
[20210209111814780.png]: /images/20221024/996977fc53ae4cabae7609de70b36d6b.png
[20210209111735852.png_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDM1MzUwNw_size_16_color_FFFFFF_t_70]: /images/20221024/bafe2c37a13c4bf5be6f7b2c49848619.png
[2021020918330025.png]: /images/20221024/56de3ffba67e4d9282036401ce9e06cf.png
[20210209184443291.png]: /images/20221024/8b967e583845468a8eaca4c8e1bd92ce.png