redis定時(shí)刪除功能有哪些

redis定時(shí)刪除功能有哪些？這個(gè)問(wèn)題可能是我們?nèi)粘W(xué)習(xí)或工作經(jīng)常見(jiàn)到的。希望通過(guò)這個(gè)問(wèn)題能讓你收獲頗深。下面是小編給大家?guī)?lái)的參考內(nèi)容，讓我們一起來(lái)看看吧！

Redis超時(shí)刪除三種可能的答案，它們分別代表了三種不同的刪除策略：

定時(shí)刪除：在設(shè)置鍵的過(guò)期時(shí)間的同時(shí)，創(chuàng)建一個(gè)定時(shí)器（timer），讓定時(shí)器在鍵的過(guò)期時(shí)間來(lái)臨時(shí)，立即執(zhí)行對(duì)鍵的刪除操作。

惰性刪除：放任鍵過(guò)期不管，但是每次從鍵空間中獲取鍵時(shí)，都檢查取得的鍵是否過(guò)期，如果過(guò)期的話，就刪除該鍵；如果沒(méi)有過(guò)期，就返回該鍵。

定期刪除：每隔一段時(shí)間，程序就對(duì)數(shù)據(jù)庫(kù)進(jìn)行一次檢查，刪除里面的過(guò)期鍵。至于要?jiǎng)h除多少過(guò)期鍵，以及要檢查多少個(gè)數(shù)據(jù)庫(kù)，則由算法決定。

在這三種策略中，第一種和第三種為主動(dòng)刪除策略，而第二種則為被動(dòng)刪除策略。

定時(shí)刪除：

定時(shí)刪除策略對(duì)內(nèi)存是最友好的：通過(guò)使用定時(shí)器，定時(shí)刪除策略可以保證過(guò)期鍵會(huì)盡可能快地被刪除，并釋放過(guò)期鍵所占用的內(nèi)存。

另一方面，定時(shí)刪除策略的缺點(diǎn)是，它對(duì)CPU時(shí)間是最不友好的：在過(guò)期鍵比較多的情況下，刪除過(guò)期鍵這一行為可能會(huì)占用相當(dāng)一部分CPU時(shí)間，在內(nèi)存不緊張但是CPU時(shí)間非常緊張的情況下，將CPU時(shí)間用在刪除和當(dāng)前任務(wù)無(wú)關(guān)的過(guò)期鍵上，無(wú)疑會(huì)對(duì)服務(wù)器的響應(yīng)時(shí)間和吞吐量造成影響。

例如，如果正有大量的命令請(qǐng)求在等待服務(wù)器處理，并且服務(wù)器當(dāng)前不缺少內(nèi)存，那么服務(wù)器應(yīng)該優(yōu)先將CPU時(shí)間用在處理客戶端的命令請(qǐng)求上面，而不是用在刪除過(guò)期鍵上面。

除此之外，創(chuàng)建一個(gè)定時(shí)器需要用到Redis服務(wù)器中的時(shí)間事件，而當(dāng)前時(shí)間事件的實(shí)現(xiàn)方式——無(wú)序鏈表，查找一個(gè)事件的時(shí)間復(fù)雜度為O（N）——并不能高效地處理大量時(shí)間事件。

因此，要讓服務(wù)器創(chuàng)建大量的定時(shí)器，從而實(shí)現(xiàn)定時(shí)刪除策略，在現(xiàn)階段來(lái)說(shuō)并不現(xiàn)實(shí)。

惰性刪除：

惰性刪除策略對(duì)CPU時(shí)間來(lái)說(shuō)是最友好的：程序只會(huì)在取出鍵時(shí)才對(duì)鍵進(jìn)行過(guò)期檢查，這可以保證刪除過(guò)期鍵的操作只會(huì)在非做不可的情況下進(jìn)行，并且刪除的目標(biāo)僅限于當(dāng)前處理的鍵，這個(gè)策略不會(huì)在刪除其他無(wú)關(guān)的過(guò)期鍵上花費(fèi)任何CPU時(shí)間。

惰性刪除策略的缺點(diǎn)是，它對(duì)內(nèi)存是最不友好的：如果一個(gè)鍵已經(jīng)過(guò)期，而這個(gè)鍵又仍然保留在數(shù)據(jù)庫(kù)中，那么只要這個(gè)過(guò)期鍵不被刪除，它所占用的內(nèi)存就不會(huì)釋放。

在使用惰性刪除策略時(shí)，如果數(shù)據(jù)庫(kù)中有非常多的過(guò)期鍵，而這些過(guò)期鍵又恰好沒(méi)有被訪問(wèn)到的話，那么它們也許永遠(yuǎn)也不會(huì)被刪除（除非用戶手動(dòng)執(zhí)行FLUSHDB），我們甚至可以將這種情況看作是一種內(nèi)存泄漏——無(wú)用的垃圾數(shù)據(jù)占用了大量的內(nèi)存，而服務(wù)器卻不會(huì)自己去釋放它們，這對(duì)于運(yùn)行狀態(tài)非常依賴于內(nèi)存的Redis服務(wù)器來(lái)說(shuō)，肯定不是一個(gè)好消息。

舉個(gè)例子，對(duì)于一些和時(shí)間有關(guān)的數(shù)據(jù)，比如日志（log），在某個(gè)時(shí)間點(diǎn)之后，對(duì)它們的訪問(wèn)就會(huì)大大減少，甚至不再訪問(wèn)，如果這類過(guò)期數(shù)據(jù)大量地積壓在數(shù)據(jù)庫(kù)中，用戶以為服務(wù)器已經(jīng)自動(dòng)將它們刪除了，但實(shí)際上這些鍵仍然存在，而且鍵所占用的內(nèi)存也沒(méi)有釋放，那么造成的后果肯定是非常嚴(yán)重的。

定期刪除：

從上面對(duì)定時(shí)刪除和惰性刪除的討論來(lái)看，這兩種刪除方式在單一使用時(shí)都有明顯的缺陷：

·定時(shí)刪除占用太多CPU時(shí)間，影響服務(wù)器的響應(yīng)時(shí)間和吞吐量。

·惰性刪除浪費(fèi)太多內(nèi)存，有內(nèi)存泄漏的危險(xiǎn)。

定期刪除策略是前兩種策略的一種整合和折中：

·定期刪除策略每隔一段時(shí)間執(zhí)行一次刪除過(guò)期鍵操作，并通過(guò)限制刪除操作執(zhí)行的時(shí)長(zhǎng)和頻率來(lái)減少刪除操作對(duì)CPU時(shí)間的影響。

·除此之外，通過(guò)定期刪除過(guò)期鍵，定期刪除策略有效地減少了因?yàn)檫^(guò)期鍵而帶來(lái)的內(nèi)存浪費(fèi)。

定期刪除策略的難點(diǎn)是確定刪除操作執(zhí)行的時(shí)長(zhǎng)和頻率：

·如果刪除操作執(zhí)行得太頻繁，或者執(zhí)行的時(shí)間太長(zhǎng)，定期刪除策略就會(huì)退化成定時(shí)刪除策略，以至于將CPU時(shí)間過(guò)多地消耗在刪除過(guò)期鍵上面。

·如果刪除操作執(zhí)行得太少，或者執(zhí)行的時(shí)間太短，定期刪除策略又會(huì)和惰性刪除策略一樣，出現(xiàn)浪費(fèi)內(nèi)存的情況。

過(guò)期鍵的定期刪除策略由redis.c/activeExpireCycle函數(shù)實(shí)現(xiàn)，每當(dāng)Redis的服務(wù)器周期性操作redis.c/serverCron函數(shù)執(zhí)行時(shí)，activeExpireCycle函數(shù)就會(huì)被調(diào)用，它在規(guī)定的時(shí)間內(nèi)，分多次遍歷服務(wù)器中的各個(gè)數(shù)據(jù)庫(kù)，從數(shù)據(jù)庫(kù)的expires字典中隨機(jī)檢查一部分鍵的過(guò)期時(shí)間，并刪除其中的過(guò)期鍵。

整個(gè)過(guò)程可以用偽代碼描述如下：

#
默認(rèn)每次檢查的數(shù)據(jù)庫(kù)數(shù)量
DEFAULT_DB_NUMBERS = 16
#
默認(rèn)每個(gè)數(shù)據(jù)庫(kù)檢查的鍵數(shù)量
DEFAULT_KEY_NUMBERS = 20
#
全局變量，記錄檢查進(jìn)度
current_db = 0
def activeExpireCycle():
    #
初始化要檢查的數(shù)據(jù)庫(kù)數(shù)量
    #
如果服務(wù)器的數(shù)據(jù)庫(kù)數(shù)量比 DEFAULT_DB_NUMBERS
要小
    #
那么以服務(wù)器的數(shù)據(jù)庫(kù)數(shù)量為準(zhǔn)
    if server.dbnum < DEFAULT_DB_NUMBERS:
        db_numbers = server.dbnum
    else:
        db_numbers = DEFAULT_DB_NUMBERS
    #
遍歷各個(gè)數(shù)據(jù)庫(kù)
    for i in range(db_numbers):
        #
如果current_db
的值等于服務(wù)器的數(shù)據(jù)庫(kù)數(shù)量
        #
這表示檢查程序已經(jīng)遍歷了服務(wù)器的所有數(shù)據(jù)庫(kù)一次
        #
將current_db
重置為0
，開(kāi)始新的一輪遍歷
        if current_db == server.dbnum:
            current_db = 0
        #
獲取當(dāng)前要處理的數(shù)據(jù)庫(kù)
        redisDb = server.db[current_db]
        #
將數(shù)據(jù)庫(kù)索引增1
，指向下一個(gè)要處理的數(shù)據(jù)庫(kù)
        current_db += 1
        #
檢查數(shù)據(jù)庫(kù)鍵
        for j in range(DEFAULT_KEY_NUMBERS):
            #
如果數(shù)據(jù)庫(kù)中沒(méi)有一個(gè)鍵帶有過(guò)期時(shí)間，那么跳過(guò)這個(gè)數(shù)據(jù)庫(kù)
            if redisDb.expires.size() == 0: break
            #
隨機(jī)獲取一個(gè)帶有過(guò)期時(shí)間的鍵
            key_with_ttl = redisDb.expires.get_random_key()
            #
檢查鍵是否過(guò)期，如果過(guò)期就刪除它
            if is_expired(key_with_ttl):
                delete_key(key_with_ttl)
            #
已達(dá)到時(shí)間上限，停止處理
            if reach_time_limit(): return

activeExpireCycle函數(shù)的工作模式可以總結(jié)如下：

·函數(shù)每次運(yùn)行時(shí)，都從一定數(shù)量的數(shù)據(jù)庫(kù)中取出一定數(shù)量的隨機(jī)鍵進(jìn)行檢查，并刪除其中的過(guò)期鍵。

·全局變量current_db會(huì)記錄當(dāng)前activeExpireCycle函數(shù)檢查的進(jìn)度，并在下一次activeExpireCycle函數(shù)調(diào)用時(shí)，接著上一次的進(jìn)度進(jìn)行處理。比如說(shuō)，如果當(dāng)前activeExpireCycle函數(shù)在遍歷10號(hào)數(shù)據(jù)庫(kù)時(shí)返回了，那么下次activeExpireCycle函數(shù)執(zhí)行時(shí)，將從11號(hào)數(shù)據(jù)庫(kù)開(kāi)始查找并刪除過(guò)期鍵。

·隨著activeExpireCycle函數(shù)的不斷執(zhí)行，服務(wù)器中的所有數(shù)據(jù)庫(kù)都會(huì)被檢查一遍，這時(shí)函數(shù)將current_db變量重置為0，然后再次開(kāi)始新一輪的檢查工作。

感謝各位的閱讀！看完上述內(nèi)容，你們對(duì)redis定時(shí)刪除功能有哪些大概了解了嗎？希望文章內(nèi)容對(duì)大家有所幫助。如果想了解更多相關(guān)文章內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道。