理解Redis的內存回收機制

以前看到過一道面試題：Redis的過時策略都有哪些？內存淘汰機制都有哪些？手寫一下LRU代碼實現？筆者結合在工做上遇到的問題學習分析，但願看完這篇文章能對你們有所幫助。

從一次不可描述的故障提及

問題描述：一個依賴於定時器任務的生成的接口列表數據，時而有，時而沒有。

懷疑是Redis過時刪除策略

排查過程長，由於手動執行定時器，set數據沒有報錯，可是set數據以後不生效。

set沒報錯，可是set完再查的狀況下沒數據，開始懷疑Redis的過時刪除策略（準確來講應該是Redis的內存回收機制中的數據淘汰策略觸發內存上限淘汰數據。），致使新加入Redis的數據都被丟棄了。最終發現故障的緣由是由於配置錯了，致使數據寫錯地方，並非Redis的內存回收機制引發。

經過此次故障後思考總結，若是下一次遇到相似的問題，在懷疑Redis的內存回收以後，如何有效地證實它的正確性？如何快速證實猜想的正確與否？以及什麼狀況下懷疑內存回收纔是合理的呢？下一次若是再次遇到相似問題，就可以更快更準地定位問題的緣由。另外，Redis的內存回收機制原理也須要掌握，明白是什麼，爲何。

花了點時間查閱資料研究Redis的內存回收機制，並閱讀了內存回收的實現代碼，經過代碼結合理論，給你們分享一下Redis的內存回收機制。

爲何須要內存回收？

一、在Redis中，set指令能夠指定key的過時時間，當過時時間到達之後，key就失效了；

二、Redis是基於內存操做的，全部的數據都是保存在內存中，一臺機器的內存是有限且很寶貴的。

基於以上兩點，爲了保證Redis能繼續提供可靠的服務，Redis須要一種機制清理掉不經常使用的、無效的、多餘的數據，失效後的數據須要及時清理，這就須要內存回收了。

Redis的內存回收機制

Redis的內存回收主要分爲過時刪除策略和內存淘汰策略兩部分。

過時刪除策略

刪除達到過時時間的key。

一、定時刪除

對於每個設置了過時時間的key都會建立一個定時器，一旦到達過時時間就當即刪除。該策略能夠當即清除過時的數據，對內存較友好，可是缺點是佔用了大量的CPU資源去處理過時的數據，會影響Redis的吞吐量和響應時間。

二、惰性刪除

當訪問一個key時，才判斷該key是否過時，過時則刪除。該策略能最大限度地節省CPU資源，可是對內存卻十分不友好。有一種極端的狀況是可能出現大量的過時key沒有被再次訪問，所以不會被清除，致使佔用了大量的內存。

在計算機科學中，懶惰刪除（英文：lazy deletion）指的是從一個散列表（也稱哈希表）中刪除元素的一種方法。在這個方法中，刪除僅僅是指標記一個元素被刪除，而不是整個清除它。被刪除的位點在插入時被看成空元素，在搜索之時被看成已佔據。

三、按期刪除

每隔一段時間，掃描Redis中過時key字典，並清除部分過時的key。該策略是前二者的一個折中方案，還能夠經過調整定時掃描的時間間隔和每次掃描的限定耗時，在不一樣狀況下使得CPU和內存資源達到最優的平衡效果。

在Redis中，同時使用了按期刪除和惰性刪除。

過時刪除策略原理

爲了你們聽起來不會以爲疑惑，在正式介紹過時刪除策略原理以前，先給你們介紹一點可能會用到的相關Redis基礎知識。

redisDb結構體定義

咱們知道，Redis是一個鍵值對數據庫，對於每個redis數據庫，redis使用一個redisDb的結構體來保存，它的結構以下：

typedef struct redisDb {

        dict *dict;                /* 數據庫的鍵空間，保存數據庫中的全部鍵值對 */

        dict *expires;              /* 保存全部過時的鍵 */

        dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP)*/

        dict *ready_keys;          /* Blocked keys that received a PUSH */

        dict *watched_keys;        /* WATCHED keys for MULTI/EXEC CAS */

        int id;                    /* 數據庫ID字段，表明不一樣的數據庫 */

        long long avg_ttl;          /* Average TTL, just for stats */

} redisDb;

從結構定義中咱們能夠發現，對於每個Redis數據庫，都會使用一個字典的數據結構來保存每個鍵值對，dict的結構圖以下：

 

 

 

以上就是過時策略實現時用到比較核心的數據結構。程序=數據結構+算法，介紹完數據結構之後，接下來繼續看看處理的算法是怎樣的。

expires屬性

redisDb定義的第二個屬性是expires，它的類型也是字典，Redis會把全部過時的鍵值對加入到expires，以後再經過按期刪除來清理expires裏面的值。加入expires的場景有：

一、set指定過時時間expire

若是設置key的時候指定了過時時間，Redis會將這個key直接加入到expires字典中，並將超時時間設置到該字典元素。

二、調用expire命令

顯式指定某個key的過時時間

三、恢復或修改數據

從Redis持久化文件中恢復文件或者修改key，若是數據中的key已經設置了過時時間，就將這個key加入到expires字典中

以上這些操做都會將過時的key保存到expires。redis會按期從expires字典中清理過時的key。

Redis清理過時key的時機

一、Redis在啓動的時候，會註冊兩種事件，一種是時間事件，另外一種是文件事件。（可參考啓動Redis的時候，Redis作了什麼）時間事件主要是Redis處理後臺操做的一類事件，好比客戶端超時、刪除過時key；文件事件是處理請求。

在時間事件中，redis註冊的回調函數是serverCron，在定時任務回調函數中，經過調用databasesCron清理部分過時key。（這是按期刪除的實現。）

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData)

{

    …

    /* Handle background operations on Redis databases. */

    databasesCron();

    ...

}

二、每次訪問key的時候，都會調用expireIfNeeded函數判斷key是否過時，若是是，清理key。（這是惰性刪除的實現。）

robj *lookupKeyRead(redisDb *db, robj *key) {

    robj *val;

    expireIfNeeded(db,key);

    val = lookupKey(db,key);

    ...

    return val;

}

三、每次事件循環執行時，主動清理部分過時key。（這也是惰性刪除的實現。）

void aeMain(aeEventLoop *eventLoop) {

    eventLoop->stop = 0;

    while (!eventLoop->stop) {

        if (eventLoop->beforesleep != NULL)

            eventLoop->beforesleep(eventLoop);

        aeProcessEvents(eventLoop, AE_ALL_EVENTS);

    }

}

void beforeSleep(struct aeEventLoop *eventLoop) {

      ...

      /* Run a fast expire cycle (the called function will return

        - ASAP if a fast cycle is not needed). */

      if (server.active_expire_enabled && server.masterhost == NULL)

          activeExpireCycle(ACTIVE_EXPIRE_CYCLE_FAST);

      ...

  }

過時策略的實現

咱們知道，Redis是以單線程運行的，在清理key是不能佔用過多的時間和CPU，須要在儘可能不影響正常的服務狀況下，進行過時key的清理。過時清理的算法以下：

一、server.hz配置了serverCron任務的執行週期，默認是10，即CPU空閒時每秒執行十次。

二、每次清理過時key的時間不能超過CPU時間的25%：timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;

    好比，若是hz=1，一次清理的最大時間爲250ms，hz=10，一次清理的最大時間爲25ms。

三、若是是快速清理模式（在beforeSleep函數調用），則一次清理的最大時間是1ms。

四、依次遍歷全部的DB。

五、從db的過時列表中隨機取20個key，判斷是否過時，若是過時，則清理。

六、若是有5個以上的key過時，則重複步驟5，不然繼續處理下一個db

七、在清理過程當中，若是達到CPU的25%時間，退出清理過程。

從實現的算法中能夠看出，這只是基於機率的簡單算法，且是隨機的抽取，所以是沒法刪除全部的過時key，經過調高hz參數能夠提高清理的頻率，過時key能夠更及時的被刪除，但hz過高會增長CPU時間的消耗。

刪除key

Redis4.0之前，刪除指令是del，del會直接釋放對象的內存，大部分狀況下，這個指令很是快，沒有任何延遲的感受。可是，若是刪除的key是一個很是大的對象，好比一個包含了千萬元素的hash，那麼刪除操做就會致使單線程卡頓，Redis的響應就慢了。爲了解決這個問題，在Redis4.0版本引入了unlink指令，能對刪除操做進行「懶」處理，將刪除操做丟給後臺線程，由後臺線程來異步回收內存。

實際上，在判斷key須要過時以後，真正刪除key的過程是先廣播expire事件到從庫和AOF文件中，而後在根據redis的配置決定當即刪除仍是異步刪除。

若是是當即刪除，Redis會當即釋放key和value佔用的內存空間，不然，Redis會在另外一個bio線程中釋放須要延遲刪除的空間。

小結

總的來講，Redis的過時刪除策略是在啓動時註冊了serverCron函數，每個時間時鐘週期，都會抽取expires字典中的部分key進行清理，從而實現按期刪除。另外，Redis會在訪問key時判斷key是否過時，若是過時了，就刪除，以及每一次Redis訪問事件到來時，beforeSleep都會調用activeExpireCycle函數，在1ms時間內主動清理部分key，這是惰性刪除的實現。

Redis結合了按期刪除和惰性刪除，基本上能很好的處理過時數據的清理，可是實際上仍是有點問題的，若是過時key較多，按期刪除漏掉了一部分，並且也沒有及時去查，即沒有走惰性刪除，那麼就會有大量的過時key堆積在內存中，致使redis內存耗盡，當內存耗盡以後，有新的key到來會發生什麼事呢？是直接拋棄仍是其餘措施呢？有什麼辦法能夠接受更多的key？

內存淘汰策略

Redis的內存淘汰策略，是指內存達到maxmemory極限時，使用某種算法來決定清理掉哪些數據，以保證新數據的存入。

Redis的內存淘汰機制

noeviction: 當內存不足以容納新寫入數據時，新寫入操做會報錯。

allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間（server.db[i].dict）中，移除最近最少使用的 key（這個是最經常使用的）。

allkeys-random：當內存不足以容納新寫入數據時，在鍵空間（server.db[i].dict）中，隨機移除某個 key。

volatile-lru：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間（server.db[i].expires）中，移除最近最少使用的 key。

volatile-random：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間（server.db[i].expires）中，隨機移除某個 key。

volatile-ttl：當內存不足以容納新寫入數據時，在設置了過時時間的鍵空間（server.db[i].expires）中，有更早過時時間的 key 優先移除。

在配置文件中，經過maxmemory-policy能夠配置要使用哪個淘汰機制。

何時會進行淘汰？

Redis會在每一次處理命令的時候（processCommand函數調用freeMemoryIfNeeded）判斷當前redis是否達到了內存的最大限制，若是達到限制，則使用對應的算法去處理須要刪除的key。僞代碼以下：

int processCommand(client *c)

{

    ...

    if (server.maxmemory) {

        int retval = freeMemoryIfNeeded(); 

    }

    ...

}

LRU實現原理

在淘汰key時，Redis默認最經常使用的是LRU算法（Latest Recently Used）。Redis經過在每個redisObject保存lru屬性來保存key最近的訪問時間，在實現LRU算法時直接讀取key的lru屬性。

具體實現時，Redis遍歷每個db，從每個db中隨機抽取一批樣本key，默認是3個key，再從這3個key中，刪除最近最少使用的key。實現僞代碼以下：

keys = getSomeKeys(dict, sample)

key = findSmallestIdle(keys)

remove(key)

3這個數字是配置文件中的maxmeory-samples字段，也是能夠能夠設置採樣的大小，若是設置爲10，那麼效果會更好，不過也會耗費更多的CPU資源。

以上就是Redis內存回收機制的原理介紹，瞭解了上面的原理介紹後，回到一開始的問題，在懷疑Redis內存回收機制的時候能不能及時判斷故障是否是由於Redis的內存回收機制致使的呢？

回到問題原點

如何證實故障是否是由內存回收機制引發的？

根據前面分析的內容，若是set沒有報錯，可是不生效，只有兩種狀況：

一、設置的過時時間太短，好比，1s？

二、內存超過了最大限制，且設置的是noeviction或者allkeys-random。

所以，在遇到這種狀況，首先看set的時候是否加了過時時間，且過時時間是否合理，若是過時時間較短，那麼應該檢查一下設計是否合理。

若是過時時間沒問題，那就須要查看Redis的內存使用率，查看Redis的配置文件或者在Redis中使用info命令查看Redis的狀態，maxmemory屬性查看最大內存值。若是是0，則沒有限制，此時是經過total_system_memory限制，對比used_memory與Redis最大內存，查看內存使用率。

若是當前的內存使用率較大，那麼就須要查看是否有配置最大內存，若是有且內存超了，那麼就能夠初步斷定是內存回收機制致使key設置不成功，還須要查看內存淘汰算法是否noeviction或者allkeys-random，若是是，則能夠確認是redis的內存回收機制致使。若是內存沒有超，或者內存淘汰算法不是上面的二者，則還須要看看key是否已通過期，經過ttl查看key的存活時間。若是運行了程序，set沒有報錯，則ttl應該立刻更新，不然說明set失敗，若是set失敗了那麼就應該查看操做的程序代碼是否正確了。

 

 

 

總結

Redis對於內存的回收有兩種方式，一種是過時key的回收，另外一種是超過redis的最大內存後的內存釋放。

對於第一種狀況，Redis會在：

一、每一次訪問的時候判斷key的過時時間是否到達，若是到達，就刪除key

二、redis啓動時會建立一個定時事件，會按期清理部分過時的key，默認是每秒執行十次檢查，每次過時key清理的時間不超過CPU時間的25%，即若hz=1，則一次清理時間最大爲250ms，若hz=10，則一次清理時間最大爲25ms。

對於第二種狀況，redis會在每次處理redis命令的時候判斷當前redis是否達到了內存的最大限制，若是達到限制，則使用對應的算法去處理須要刪除的key。