Redis服務(wù)器實(shí)際使用的是惰性刪除和定期刪除兩種策略：通過配合使用這兩種刪除策略，服務(wù)器可以很好地在合理使用CPU時(shí)間和避免浪費(fèi)內(nèi)存空間之間取得平衡。

惰性刪除

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

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

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

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

定期刪除

從上面對惰性刪除的討論來看，這刪除方式在單一使用時(shí)有明顯的缺陷：

惰性刪除浪費(fèi)太多內(nèi)存，有內(nèi)存泄漏的危險(xiǎn)。定期刪除策略是前兩種策略的一種整合和折中：

定期刪除策略每隔一段時(shí)間執(zhí)行一次刪除過期鍵操作，并通過限制刪除操作執(zhí)行的時(shí)長和頻率來減少刪除操作對CPU時(shí)間的影響。除此之外，通過定期刪除過期鍵，定期刪除策略有效地減少了因?yàn)檫^期鍵而帶來的內(nèi)存浪費(fèi)。定期刪除策略的難點(diǎn)是確定刪除操作執(zhí)行的時(shí)長和頻率：

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

如果刪除操作執(zhí)行得太少，或者執(zhí)行的時(shí)間太短，定期刪除策略又會(huì)和惰性刪除策略一樣，出現(xiàn)浪費(fèi)內(nèi)存的情況。因此，如果采用定期刪除策略的話，服務(wù)器必須根據(jù)情況，合理地設(shè)置刪除操作的執(zhí)行時(shí)長和執(zhí)行頻率。

惰性刪除策略

過期鍵的惰性刪除策略由db.c/expireIfNeeded函數(shù)實(shí)現(xiàn)，所有讀寫數(shù)據(jù)庫的Redis命令在執(zhí)行之前都會(huì)調(diào)用expireIfNeeded函數(shù)對輸入鍵進(jìn)行檢查：

如果輸入鍵已經(jīng)過期，那么expireIfNeeded函數(shù)將輸入鍵從數(shù)據(jù)庫中刪除。

如果輸入鍵未過期，那么expireIfNeeded函數(shù)不做動(dòng)作。

expireIfNeeded函數(shù)就像一個(gè)過濾器，它可以在命令真正執(zhí)行之前，過濾掉過期的輸入鍵，從而避免命令接觸到過期鍵。

另外，因?yàn)槊總€(gè)被訪問的鍵都可能因?yàn)檫^期而被expireIfNeeded函數(shù)刪除，所以每個(gè)命令的實(shí)現(xiàn)函數(shù)都必須能同時(shí)處理鍵存在以及鍵不存在這兩種情況：

當(dāng)鍵存在時(shí)，命令按照鍵存在的情況執(zhí)行。

當(dāng)鍵不存在或者鍵因?yàn)檫^期而被expireIfNeeded函數(shù)刪除時(shí)，命令按照鍵不存在的情況執(zhí)行。

定期刪除策略的實(shí)現(xiàn)

過期鍵的定期刪除策略由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ù)庫，從數(shù)據(jù)庫的expires字典中隨機(jī)檢查一部分鍵的過期時(shí)間，并刪除其中的過期鍵。

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

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

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

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

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

當(dāng)服務(wù)器運(yùn)行在復(fù)制模式下時(shí)，從服務(wù)器的過期鍵刪除動(dòng)作由主服務(wù)器控制：

主服務(wù)器在刪除一個(gè)過期鍵之后，會(huì)顯式地向所有從服務(wù)器發(fā)送一個(gè)DEL命令，告知從服務(wù)器刪除這個(gè)過期鍵。

從服務(wù)器在執(zhí)行客戶端發(fā)送的讀命令時(shí)，即使碰到過期鍵也不會(huì)將過期鍵刪除，而是繼續(xù)像處理未過期的鍵一樣來處理過期鍵

從服務(wù)器只有在接到主服務(wù)器發(fā)來的DEL命令之后，才會(huì)刪除過期鍵。

通過由主服務(wù)器來控制從服務(wù)器統(tǒng)一地刪除過期鍵，可以保證主從服務(wù)器數(shù)據(jù)的一致性，也正是因?yàn)檫@個(gè)原因，當(dāng)一個(gè)過期鍵仍然存在于主服務(wù)器的數(shù)據(jù)庫時(shí)，這個(gè)過期鍵在從服務(wù)器里的復(fù)制品也會(huì)繼續(xù)存在。舉個(gè)例子，有一對主從服務(wù)器，它們的數(shù)據(jù)庫中都保存著同樣的三個(gè)鍵message、xxx和yyy，其中message為過期鍵，如圖所示。

如果這時(shí)有客戶端向從服務(wù)器發(fā)送命令GET message，那么從服務(wù)器將發(fā)現(xiàn)message鍵已經(jīng)過期，但從服務(wù)器并不會(huì)刪除message鍵，而是繼續(xù)將message鍵的值返回給客戶端，就好像message鍵并沒有過期一樣

假設(shè)在此之后，有客戶端向主服務(wù)器發(fā)送命令GET message，那么主服務(wù)器將發(fā)現(xiàn)鍵message已經(jīng)過期：主服務(wù)器會(huì)刪除message鍵，向客戶端返回空回復(fù)，并向從服務(wù)器發(fā)送DEL message命令

從服務(wù)器在接收到主服務(wù)器發(fā)來的DEL message命令之后，也會(huì)從數(shù)據(jù)庫中刪除message鍵，在這之后，主從服務(wù)器都不再保存過期鍵message了

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評論