數據緩存歷險記（三）--老頭的LRU很帶勁

「這是我參與8月更文挑戰的第5天，活動詳情查看：8月更文挑戰」

"數據緩存歷險記第二篇被過時鍵經理上了一課"

"數據緩存歷險記第一篇被淘汰警察上了一課"

話說上期

數據又回來了，想起昨天被過時經理上了一課，雖然內心非常難過，可是畢竟知道人外有人，原來爲了控制咱們數據，制定了這麼野性的過時鍵策略，據說後面的關更難了， 可是仍是要闖關一下了，不是還有那句話嘛， 關關難過關關過

緩存淘汰策略

據說有個老頭叫緩存淘汰策略，比過時鍵經理還有實力，好多難找的數據，都能被他找到，通過他這麼一整，Redis總統的管理起來就很容易了，爲了能夠更好的瞭解到接下來緩存淘汰策略，越戰越勇的數據，揹着本身的value心靈仍是出發了，

一路通過了過時鍵經理的送別，遊蕩在半路上，碰見了一個老頭，說你是來自過時鍵經理的數據吧，數據連忙驚訝，哇靠，這老頭連我從哪裏來的都知道，莫不是；

---

是的，我就是那個老頭，說完就哈哈大笑起來。

何時會碰見這個老頭呢？

緩存淘汰策略觸發的條件：

• 當前緩存空間臨界最大memeory
• 當前須要業務改變，須要調整緩存策略
• 對於選中鍵值對，全部鍵值對作過濾時候

最直接的就是： 好比就是當內存maxmemory不夠用了，就會啓用內存淘汰策略了；

老頭手裏有祕笈

專門治理緩存中的無量數據，

其中分爲兩個維度，四個方面---》八種結果；

維度

①過時鍵中篩選

②因此key中篩選

四個方面

• LRU
• LFU
• RANDOM
• TTL

八種緩存淘汰策略：

其中兩個縮寫： LRU: least recently used 最近最少使用(Least Recently Used)；最近最少使用算法 LFU: least frequently Used 置換算法(Least Frequently Used) 最近頻率算法

LRU 和最小 TTL 算法不是精確算法而是近似算法

首先呢，數據就先肯定了有八種緩存淘汰策略，各有優點；

三大問題，就出如今數據腦海中

1.通常本地會用什麼緩存淘汰策略呢？

2.如何修改緩存淘汰策略呢？

3.最近比較火緩存淘汰機制LRU思想是啥？

解析問題1：

1.通常本地會用什麼緩存淘汰策略呢？

若是是本身本地已經下載了Redis，通常在配置文件conf中會找到，關於 memory-policy的字段，其中配置的值爲noevcation的，不會驅逐

表示對於緩存中的數據，不作淘汰，便是緩存內存奔潰；

解析問題2：

2.如何修改緩存淘汰策略呢？

兩種方式，一種是命令，一種是conf的方式：

命令方式：

config set maxmemory-policy allkeys-lru
複製代碼

conf文件

# maxmemory-policy noevication  不會驅逐，會致使redis奔潰
maxmeory-policy allkeys-lru
複製代碼

解析問題3：

3.最近比較火緩存淘汰機制LRU思想是啥？

LRU: Least Recently Used的縮寫； 即最近最少使用，的一種頁面置換算法

本質上

此算法會過濾出最近最久未使用的數據予以淘汰

實例場景：

手機的後臺任務，一個任務屢次使用，會默認提示他的加載能力，特別少使用的會放在最左側 ，直到內存發生空間緊張，優先使用LRU;

此算法就是來源於力扣的算法， LRU的緩存機制；

LRU算法的思想：

所謂緩存： 是讀和寫的操做， 最好在O(1)狀態機制下，完成讀與寫的過程

特性要求：

• 必需要有順序之分，由於根據排序，留存的時間區分

• 讀寫操做一次搞定，符合O（1）的狀態

• 若是緩存容量滿了，刪除不經常使用的數據，

• 每次訪問要把最新的數據插入隊頭中去；

  綜上所述：

查找快，刪除快，插入快，且還須要注意順序的數據結構

就是哈希鏈表；

其中哈希：查找 鏈表：插入和刪除快，還要有順序， 雙向鏈表

三個問題有了答案以後，數據感受頓時對老頭，內心的敬畏之情誼，

這老頭對於LRU底層，多個緩存淘汰策略的制定，頗有看法，果真姜換是老的辣

數據今天的旅途非常受益

盧卡寄語

經過對數據通過過時鍵，到緩存淘汰策略，一次次是將數據過濾，減小內存的損耗，

其中LRU算法思想在於多個場景技術中都用到過，好比手機的多任務，就是簡單的LRU來作的， 下期是盧卡帶你手寫LRU算法， 期待數據又更好的表現，晚安了