Redis緩存三大問題及內存滿了該怎么辦

日常的開發中，無不都是使用數據庫來進行數據的存儲，由於一般的系統任務中通常不會存在高並發的情況，所以這樣看起來並沒有什么問題。

一旦涉及大數據量的需求，如一些商品搶購的情景，或者主頁訪問量瞬間較大的時候，單一使用數據庫來保存數據的系統會因為面向磁盤，磁盤讀/寫速度問題有嚴重的性能弊端，詳細的磁盤讀寫原理請參考這一片[]。

在這一瞬間成千上萬的請求到來，需要系統在極短的時間內完成成千上萬次的讀/寫操作，這個時候往往不是數據庫能夠承受的，極其容易造成數據庫系統癱瘓，最終導致服務宕機的嚴重生產問題。

為了克服上述的問題，項目通常會引入NoSQL技術，這是一種基於內存的數據庫，並且提供一定的持久化功能。

Redis技術就是NoSQL技術中的一種。Redis緩存的使用，極大的提升了應用程序的性能和效率，特別是數據查詢方面。

但同時，它也帶來了一些問題。其中，最要害的問題，就是數據的一致性問題，從嚴格意義上講，這個問題無解。如果對數據的一致性要求很高，那么就不能使用緩存。

另外的一些典型問題就是，緩存穿透、緩存擊穿和緩存雪崩。本篇文章從實際代碼操作，來提出解決這三個緩存問題的方案，畢竟Redis的緩存問題是實際面試中高頻問點，理論和實操要兼得。

緩存穿透

緩存穿透是指查詢一條數據庫和緩存都沒有的一條數據，就會一直查詢數據庫，對數據庫的訪問壓力就會增大，緩存穿透的解決方案，有以下兩種：

1. 緩存空對象：代碼維護較簡單，但是效果不好。

2. 布隆過濾器：代碼維護復雜，效果很好。

緩存空對象

緩存空對象是指當一個請求過來緩存中和數據庫中都不存在該請求的數據，第一次請求就會跳過緩存進行數據庫的訪問，並且訪問數據庫后返回為空，此時也將該空對象進行緩存。

若是再次進行訪問該空對象的時候，就會直接擊中緩存，而不是再次數據庫，緩存空對象實現的原理圖如下：

 

 

 

緩存空對象的實現代碼如下：

public class UserServiceImpl {
     @Autowired
     UserDAO userDAO;
     @Autowired
     RedisCache redisCache;

     public User findUser(Integer id) {
          Object object = redisCache.get(Integer.toString(id));
          // 緩存中存在，直接返回
          if(object != null) {
               // 檢驗該對象是否為緩存空對象，是則直接返回null
               if(object instanceof NullValueResultDO) {
                    return null;
               }
               return (User)object;
          } else {  
               // 緩存中不存在，查詢數據庫
               User user = userDAO.getUser(id);
               // 存入緩存
               if(user != null) {
                    redisCache.put(Integer.toString(id),user);
               } else {
                    // 將空對象存進緩存
                    redisCache.put(Integer.toString(id), new NullValueResultDO());
               }
               return user;
          }
     }          
}

緩存空對象的實現代碼很簡單，但是緩存空對象會帶來比較大的問題，就是緩存中會存在很多空對象，占用內存的空間，浪費資源，一個解決的

辦法就是設置空對象的較短的過期時間，代碼如下：

// 在緩存的時候，添加多一個該空對象的過期時間60秒
redisCache.put(Integer.toString(id), new NullValueResultDO(),60);

緩存擊穿

緩存擊穿是指一個key非常熱點，在不停的扛着大並發，大並發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大並發就穿破緩存，直接請求數據庫，瞬間對數據庫的訪問壓力增大。

緩存擊穿這里強調的是並發，造成緩存擊穿的原因有以下兩個：

1. 該數據沒有人查詢過 ，第一次就大並發的訪問。（冷門數據）

2. 添加到了緩存，reids有設置數據失效的時間 ，這條數據剛好失效，大並發訪問（熱點數據）

對於緩存擊穿的解決方案就是加鎖，具體實現的原理圖如下：

 

 當用戶出現大並發訪問的時候，在查詢緩存的時候和查詢數據庫的過程加鎖，只能第一個進來的請求進行執行，當第一個請求把該數據放進緩存中，接下來的訪問就會直接集中緩存，防止了緩存擊穿。

業界比價普遍的一種做法，即根據key獲取value值為空時，鎖上，從數據庫中load數據后再釋放鎖。若其它線程獲取鎖失敗，則等待一段時間后重試。這里要注意，分布式環境中要使用分布式鎖，單機的話用普通的鎖（synchronized、Lock）就夠了。

下面以一個獲取商品庫存的案例進行代碼的演示，單機版的鎖實現具體實現的代碼如下：

// 獲取庫存數量
public String getProduceNum(String key) {
    try {
        synchronized (this) {   //加鎖
            // 緩存中取數據，並存入緩存中
            int num= Integer.parseInt(redisTemplate.opsForValue().get(key));

            if (num> 0) {
                //沒查一次庫存-1
                redisTemplate.opsForValue().set(key, (num- 1) + "");
                System.out.println("剩余的庫存為num：" + (num- 1));
            } else {
                System.out.println("庫存為0");
            }
        }
    } catch (NumberFormatException e) {
        e.printStackTrace();
    } finally {
    }
    return "OK";
}

分布式的鎖實現具體實現的代碼如下：

public String getProduceNum(String key) {
    // 獲取分布式鎖
    RLock lock = redissonClient.getLock(key);
    try {
        // 獲取庫存數
        int num= Integer.parseInt(redisTemplate.opsForValue().get(key));  
        // 上鎖           
        lock.lock();
        if (num> 0) {
            //減少庫存，並存入緩存中
            redisTemplate.opsForValue().set(key, (num - 1) + "");
            System.out.println("剩余庫存為num：" + (num- 1));
        } else {
            System.out.println("庫存已經為0");
        }
    } catch (NumberFormatException e) {
        e.printStackTrace();
    } finally {
        //解鎖
        lock.unlock();
    }
    return "OK";
}

緩存雪崩

緩存雪崩 是指在某一個時間段，緩存集中過期失效。此刻無數的請求直接繞開緩存，直接請求數據庫。

造成緩存雪崩的原因，有以下兩種：

1. reids宕機

2. 大部分數據失效

比如天貓雙11，馬上就要到雙11零點，很快就會迎來一波搶購，這波商品在23點集中的放入了緩存，假設緩存一個小時，那么到了凌晨24點的時候，這批商品的緩存就都過期了。

而對這批商品的訪問查詢，都落到了數據庫上，對於數據庫而言，就會產生周期性的壓力波峰，對數據庫造成壓力，甚至壓垮數據庫。

緩存雪崩的原理圖如下，當正常的情況下，key沒有大量失效的用戶訪問原理圖如下：

 

 

 

當某一時間點，key大量失效，造成的緩存雪崩的原理圖如下：

 

 

對於緩存雪崩的解決方案有以下兩種：

　　1.搭建高可用的集群，防止單機的redis宕機。

　　2.設置不同的過期時間，防止同一時間內大量的key失效。

 

針對業務系統，永遠都是具體情況具體分析，沒有最好，只有最合適。於緩存其它問題，緩存滿了和數據丟失等問題，我們后面繼續深入的學習。
最后也提一下三個詞LRU、RDB、AOF，通常我們采用LRU策略處理溢出，Redis的RDB和AOF持久化策略來保證一定情況下的數據安全。

 

 

那么今天就帶來了一個面試常問的一個問題：「假如你的Redis內存滿了怎么辦？」 長期的把Redis作為緩存使用，總有一天會存滿的時候對吧。

這個面試題不慌呀，在Redis中有配置參數maxmemory可以「設置Redis內存的大小」。

在Redis的配置文件redis.conf文件中，配置maxmemory的大小參數如下所示：

 

 

實際生產中肯定不是100mb的大小哈，不要給誤導了，這里我只是讓大家認識這個參數，一般小的公司都是設置為3G左右的大小。

除了在配置文件中配置生效外，還可以通過命令行參數的形式，進行配置，具體的配置命令行如下所示：

//獲取maxmemory配置參數的大小
127.0.0.1:6379> config get maxmemory
//設置maxmemory參數為100mb
127.0.0.1:6379> config set maxmemory 100mb

倘若實際的存儲中超出了Redis的配置參數的大小時，Redis中有「淘汰策略」，把「需要淘汰的key給淘汰掉，整理出干凈的一塊內存給新的key值使用」。

接下來我們就詳細的聊一聊Redis中的淘汰策略，並且深入的理解每個淘汰策略的原理和應用的場景。

淘汰策略

Redis提供了「6種的淘汰策略」，其中默認的是noeviction，這6種淘汰策略如下：

1. noeviction(「默認策略」)：若是內存的大小達到閥值的時候，所有申請內存的指令都會報錯。
2. allkeys-lru：所有key都是使用「LRU算法」進行淘汰。
3. volatile-lru：所有「設置了過期時間的key使用LRU算法」進行淘汰。
4. allkeys-random：所有的key使用「隨機淘汰」的方式進行淘汰。
5. volatile-random：所有「設置了過期時間的key使用隨機淘汰」的方式進行淘汰。
6. volatile-ttl：所有設置了過期時間的key「根據過期時間進行淘汰，越早過期就越快被淘汰」。

假如在Redis中的數據有「一部分是熱點數據，而剩下的數據是冷門數據」，或者「我們不太清楚我們應用的緩存訪問分布狀況」，這時可以使用allkeys-lru。

假如所有的數據訪問的頻率大概一樣，就可以使用allkeys-random的淘汰策略。

假如要配置具體的淘汰策略，可以在redis.conf配置文件中配置，具體配置如下所示：

 

 這只需要把注釋給打開就可以，並且配置指定的策略方式，另一種的配置方式就是命令的方式進行配置，具體的執行命令如下所示：

// 獲取maxmemory-policy配置
127.0.0.1:6379> config get maxmemory-policy
// 設置maxmemory-policy配置為allkeys-lru
127.0.0.1:6379> config set maxmemory-policy allkeys-lru

在介紹6種的淘汰策略方式的時候，說到了LRU算法，「那么什么是LRU算法呢？」

LRU算法

LRU(Least Recently Used)即表示最近最少使用，也就是在最近的時間內最少被訪問的key，算法根據數據的歷史訪問記錄來進行淘汰數據。

它的核心的思想就是：「假如一個key值在最近很少被使用到，那么在將來也很少會被訪問」。

實際上Redis實現的LRU並不是真正的LRU算法，也就是名義上我們使用LRU算法淘汰鍵，但是實際上被淘汰的鍵並不一定是真正的最久沒用的。

Redis使用的是近似的LRU算法，「通過隨機采集法淘汰key，每次都會隨機選出5個key，然后淘汰里面最近最少使用的key」。

這里的5個key只是默認的個數，具體的個數也可以在配置文件中進行配置，在配置文件中的配置如下圖所示：

 

 

當近似LRU算法取值越大的時候就會越接近真實的LRU算法，可以這樣理解，因為「取值越大那么獲取的數據就越全，淘汰中的數據的就越接近最近最少使用的數據」。

那么為了實現根據時間實現LRU算法，Redis必須為每個key中額外的增加一個內存空間用於存儲每個key的時間，大小是3字節。

在Redis 3.0中對近似的LRU算法做了一些優化，Redis中會維護大小是16的一個候選池的內存。

當第一次隨機選取的采樣數據，數據都會被放進候選池中，並且候選池中的數據會根據時間進行排序。

當第二次以后選取的數據，只有「小於候選池內的最小時間」的才會被放進候選池中。

當某一時刻候選池的數據滿了，那么時間最大的key就會被擠出候選池。當執行淘汰時，直接從候選池中選取最近訪問時間最小的key進行淘汰。

這樣做的目的就是選取出最近似符合最近最少被訪問的key值，能夠正確的淘汰key值，因為隨機選取的樣本中的最小時間可能不是真正意義上的最小時間。

但是LRU算法有一個弊端：就是假如一個key值在以前都沒有被訪問到，然而最近一次被訪問到了，那么就會認為它是熱點數據，不會被淘汰。

然而有些數據以前經常被訪問到，只是最近的時間內沒有被訪問到，這樣就導致這些數據很可能被淘汰掉，這樣一來就會出現誤判而淘汰熱點數據。

於是在Redis 4.0的時候除了LRU算法，新加了一種LFU算法，「那么什么是LFU算法算法呢？」

 

LFU算法

LFU(Least Frequently Used)即表示最近頻繁被使用，也就是最近的時間段內，頻繁被訪問的key，它以最近的時間段的被訪問次數的頻率作為一種判斷標准。

它的核心思想就是：根據key最近被訪問的頻率進行淘汰，比較少被訪問的key優先淘汰，反之則優先保留。

LFU算法反映了一個key的熱度情況，不會因為LRU算法的偶爾一次被訪問被認為是熱點數據。

在LFU算法中支持volatile-lfu策略和allkeys-lfu策略。

以上介紹了Redis的6種淘汰策略，這6種淘汰策略旨在告訴我們怎么做，但是什么時候做？這個還沒說，下面我們就來詳細的了解Redis什么時候執行淘汰策略。

刪除過期鍵策略

在Redis中有三種刪除的操作此策略，分別是：

1. 「定時刪除」：創建一個定時器，定時的執行對key的刪除操作。
2. 「惰性刪除」：每次只有再訪問key的時候，才會檢查key的過期時間，若是已經過期了就執行刪除。
3. 「定期刪除」：每隔一段時間，就會檢查刪除掉過期的key。

「定時刪除」對於「內存來說是友好的」，定時清理出干凈的空間，但是對於「cpu來說並不是友好的」，程序需要維護一個定時器，這就會占用cpu資源。

「惰性的刪除」對於「cpu來說是友好的」，cpu不需要維護其它額外的操作，但是對於「內存來說是不友好的」，因為要是有些key一直沒有被訪問到，就會一直占用着內存。

定期刪除是上面兩種方案的折中方案**，每隔一段時間刪除過期的key，也就是根據具體的業務，合理的取一個時間定期的刪除key**。

通過「最合理控制刪除的時間間隔」來刪除key，減「少對cpu的資源的占用消耗」，使刪除操作合理化。

RDB和AOF 的淘汰處理

在Redis中持久化的方式有兩種RDB和AOF，具體這兩種詳細的持久化介紹，可以參考這一篇文章[面試造飛機系列：面對Redis持久化連環Call，你還頂得住嗎？]。

在RDB中是以快照的形式獲取內存中某一時間點的數據副本，在創建RDB文件的時候可以通過save和bgsave命令執行創建RDB文件。

「這兩個命令都不會把過期的key保存到RDB文件中」，這樣也能達到刪除過期key的效果。

當在啟動Redis載入RDB文件的時候，Master不會把過期的key載入，而Slave會把過期的key載入。

在AOF模式下，Redis提供了Rewite的優化措施，執行的命令分別是REWRITEAOF和BGREWRITEAOF，「這兩個命令都不會把過期的key寫入到AOF文件中，也能刪除過期key」。

 

摘抄來自：https://mp.weixin.qq.com/s/1HSJ-ZYSZKLVLW6mNVm4fw