Redis過時--淘汰機制的解析和內存佔用太高的解決方案

echo編輯整理，歡迎轉載，轉載請聲明文章來源。歡迎添加echo微信(微信號：t2421499075)交流學習。 百戰不敗，依不自稱常勝，百敗不頹，依能奮力前行。——這纔是真正的堪稱強大！！！

---

Redis在咱們平時的開發或者練習的時候，每每很容易忽略一個問題，那就是咱們的Redis內存佔滿的問題。可是在真是的商業開發中，Redis的實際佔盡是真正會存在這樣的問題的。那麼若是Redis在某一刻佔滿內存，咱們又沒有對它進行相應的設置它會出現什麼狀況呢？會不會致使咱們整個由於使用Redis而整個業務垮掉？這就是咱們本篇文章所要講述的問題。

什麼是Redis淘汰機制

Redis內存淘汰機制其實簡單講就是將過時的數據或者好久沒有訪問，或者在一段時間內不多有訪問的數據進行刪除。它分爲不少中，有主動的數據淘汰，如：用戶設定過時時間。有被動的淘汰，好比：Redis數據佔滿了內存，這個時候就會將過時的數據或者好久沒有訪問的數據刪除掉。

Redis的淘汰有哪些類型

• 定時過時：每一個設置過時時間的key都須要建立一個定時器，到過時時間就會當即清除。該策略能夠當即清除過時的數據，對內存很友好；可是會佔用大量的CPU資源去處理過時的數據，從而影響緩存的響應時間和吞吐量。
• 惰性過時：只有當訪問一個key時，纔會判斷該key是否已過時，過時則清除。該策略能夠最大化地節省CPU資源，卻對內存很是不友好。極端狀況可能出現大量的過時key沒有再次被訪問，從而不會被清除，佔用大量內存。
• 按期過時：每隔必定的時間，會掃描必定數量的數據庫的expires字典中必定數量的key，並清除其中已過時的key。該策略是前二者的一個折中方案。經過調整定時掃描的時間間隔和每次掃描的限定耗時，能夠在不一樣狀況下使得CPU和內存資源達到最優的平衡效果。
  (expires字典會保存全部設置了過時時間的key的過時時間數據，其中，key是指向鍵空間中的某個鍵的指針，value是該鍵的毫秒精度的UNIX時間戳表示的過時時間。鍵空間是指該Redis集羣中保存的全部鍵。)

定時過時的問題：緩存雪崩

不少人可能對這個詞很熟悉，由於有不少的商業案例展現了血淋淋的教訓，可是也有一部分人估計沒有接觸過。緩存雪崩其實也不是什麼新詞，它主要的引發緣由就是指緩存中數據大批量的到過時時間。定時過時它自己就有一個缺點，那就是會佔用大量的CPU資源，若是咱們主動設置過時時間的鍵過多，在同一時間過時，頗有可能就會造就咱們Redis掛掉。可是這並非最可怕的，雪崩不只僅影響本身，還在咱們的業務中影響數據庫。由於咱們不少業務設計都是在咱們Redis的數據過時以後，重新查詢數據庫，但咱們Redis主動批量過時的時候，會有大量的請求發送到咱們的數據庫，頗有可能致使咱們的數據庫也掛掉。這纔是最大的問題所在。

解決方案：

• 緩存數據的過時時間設置隨機，防止同一時間大量數據過時現象發生。
• 若是緩存數據庫是分佈式部署，將熱點數據均勻分佈在不一樣搞得緩存數據庫中。
• 設置熱點數據永遠不過時。

從幾種淘汰策略中其實咱們能夠看到基本的一些問題所在，因此咱們在使用緩存的時候最好有一個全面的瞭解和全面的考慮應對。在實際開發中，咱們更應該多去關注的和了解的是按期過時，由於它涉及真實開發中的一些問題。因此咱們應該提早設置好。

怎麼設置按期過時最大使用內存

按期過時的最大內存設置在咱們的redis.conf文件中，咱們能夠在該文件中看到這個配置：maxmemory <bytes>，可是這個配置通常都是註釋掉的，也就是說安裝以後若是咱們沒有主動對他進行配置，那麼他就不會有默認大小值。對應的它不設置的狀況下，那麼它可使用多少的內存空間呢？這個跟系統有關。若是說咱們將Redis安裝在32位的系統上，它的最大使用內存空間應該是在3G左右，若是是64位的系統，那麼能夠將咱們的內存佔滿。固然若是真正佔滿內存，這是一件比較惡劣的事情，不只僅訪問Redis的時候，咱們不能在進行寫的操做，並且咱們系統自己的其餘操做也會受到限制。因此咱們能夠採用命令來對它進行一個初始化的設置

config set maxmemory 268435456

使用命令進行設置以後咱們須要重啓Redis才能生效。固然咱們也能夠直接找到Redis的安裝目錄，而後使用vi命令，直接更改配置文件中的對應的該內容，更改完以後，重啓便可。

按期過時的淘汰策略

• volatile-lru:根據LRU算法生成的過時時間來刪除。
• allkeys-lru:根據LRU算法刪除任何key。
• volatile-lfu:從全部配置了過時時間的鍵中驅逐使用頻率最少的鍵
• allkeys-lfu:從全部鍵中驅逐使用頻率最少的鍵
• volatile-random:根據過時設置來隨機刪除key。
• allkeys-random:無差異隨機刪。
• volatile-ttl:根據最近過時時間來刪除（輔以TTL）
• noeviction:誰也不刪，直接在寫操做時返回錯誤。

隨機淘汰策略

隨機找hash桶再次hash指定位置的dictEntry便可。就是在場景REDIS_MAXMEMORY_VOLATILE_RANDOM和REDIS_MAXMEMORY_ALLKEYS_LRU狀況下的待淘汰的key。咱們能夠一觀它的源碼：

dictEntry *dictGetRandomKey(dict *d)
{
    dictEntry *he, *orighe;
    unsigned int h;
    int listlen, listele;
 
    if (dictSize(d) == 0) return NULL;
 
    if (dictIsRehashing(d)) _dictRehashStep(d);
 
    if (dictIsRehashing(d)) {
        // T = O(N)
        do {
            h = random() % (d->ht[0].size+d->ht[1].size);
            he = (h >= d->ht[0].size) ? d->ht[1].table[h - d->ht[0].size] :
                                      d->ht[0].table[h];
        } while(he == NULL);
    } else {
        // T = O(N)
        do {
            h = random() & d->ht[0].sizemask;
            he = d->ht[0].table[h];
        } while(he == NULL);
    }
 
    /* Now we found a non empty bucket, but it is a linked
     * list and we need to get a random element from the list.
     * The only sane way to do so is counting the elements and
     * select a random index. */
    listlen = 0;
    orighe = he;
    while(he) {
        he = he->next;
        listlen++;
    }
    listele = random() % listlen;
    he = orighe;
    // T = O(1)
    while(listele--) he = he->next;
 
    return he;
}

TTL時間淘汰

for (k = 0; k < server.maxmemory_samples; k++) {
    sds thiskey;
    long thisval;

    de = dictGetRandomKey(dict);
    thiskey = dictGetKey(de);
    thisval = (long) dictGetVal(de);

    /* Expire sooner (minor expire unix timestamp) is better
     * candidate for deletion */
    if (bestkey == NULL || thisval < bestval) {
        bestkey = thiskey;
        bestval = thisval;
    }
}

更多源碼，請參考redis官網。這裏只是簡單的展現兩種。咱們能夠根據這樣的代碼來對咱們的redis的按期過時作一個合理的配置

思考：

基於一個數據結構作緩存，怎麼實現一個LRU算法？

作一個有底線的博客主