reids過期鍵三種刪除策略

redis設計與實現(第二版)

我們知道資料庫的過期時間都儲存在過期字典中，又知道了如何根據過期時間去判斷乙個鍵是否過期，現在的問題是：如果乙個鍵過期了，那麼它什麼時候會被刪除呢？

這個問題有三種可能的答案，它們分別代表三種不同的刪除策略：

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

定時刪除：每個一段時間，程式就對資料庫進行一次檢查，刪除裡面的過期鍵。至於要刪除多少過期鍵，以及要檢查多少個資料庫，則由演算法決定。

在這三種策略中，第一種和第三種為主動刪除策略，而第二種則為被動策略

定時刪除策略對記憶體是最友好的，通過使用定時器，定時刪除策略可以保證過期鍵會盡可能地刪除，並釋放過期鍵所占用地記憶體。

另一方面，定時刪除策略地確定是，它對cpu時間是不友好地；在過期鍵比較多地情況下，刪除過期鍵這一行為可能會占用相當一部分cpu時間，在記憶體不緊張但是cpu時間非常緊張地i情況下，將cpu時間用在刪除和當前無關地過期鍵上，無疑會對伺服器地響應時間和吞吐量造成影響。

例如，如果正有大量地命令請求在等待伺服器處理，並且伺服器當前不缺少記憶體，那麼伺服器應該優先將cpu時間用在處理客戶端地命令請求上面，而不是用在刪除過期鍵上面。

除此之外，建立乙個定時器需要用到redis伺服器中地時間事件內，而當前時間事件地實現方式——無序鍊錶，查詢乙個事件地時間複雜度為o（n）——並不能高效地處理大量時間事件。

因此，要讓伺服器建立大量地定時器，從而實現定時刪除策略，在現階段來說並不是現實。

惰性刪除策略對cpu時間來說是最友好的：程式只會在取出鍵時才對鍵進行過期檢查，這可以保證刪除過期的操作只會在非做不可的情況下進行，並且刪除的目標僅限於當前處理的鍵，這個策略不會在刪除其它無關的過期鍵花費任何cpu時間。

惰性刪除策略的缺點是，它對記憶體是最不友好的；如果乙個鍵已經過期，而這個鍵又仍然保留在資料庫中，那麼只要這個過期鍵不被刪除，它所占用的記憶體就不會釋放。

在使用惰性刪除策略時，如果資料庫中有非常多的過期鍵，而這些過期鍵又恰好沒有被訪問到的話，那麼它們也許永遠也不會被刪除（除非手動執行flushdb），我們甚至可以將這種情況看作是一種記憶體洩漏——無用的垃圾占用了大量的記憶體，而伺服器卻不會自己去釋放它們，這對於執行狀態非常依賴於記憶體的redis伺服器來說，肯定不是乙個好訊息。

舉個例子，對於一些和時間有關的資料，比如日誌，在某個時間點之後，對它們的訪問就會大大減少，甚至不再訪問，如果這類過期資料大量地積壓在資料庫中，使用者以為伺服器已經自動將它們刪除了，但實際這些鍵仍然存在，而且所占用的記憶體也沒有釋放，那麼造成的後果肯定是非常嚴重的。

從上面對定時刪除和惰性刪除地討論來看，這兩種方式在單一使用時都有明顯地缺陷：

定時刪除占用太多cpu時間，影響伺服器地響應時間和吞吐量。

惰性刪除浪費太多記憶體，有記憶體洩漏地危險。

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

定期刪除策略每隔一段時間執行一次刪除操作，並通過限制刪除操作執行地時長和頻率來減少刪除操作對cpu時間地影響。

除此之外，通過定期刪除過期鍵，定時刪除策略有效地減少了因為過期鍵而帶來地記憶體消費

定期刪除策略地難點是確定刪除操作執行時長和頻率：

如果刪除操作執行得太頻繁，或者執行時間太長，定期刪除策略就會退化成定時刪除策略，以至於將cpu時間過多地消耗在刪除過期鍵上面。

如果刪除操作執行地太少，或者執行地時間太短，定期刪除策略又會和惰性刪除策略一樣，出現浪費記憶體地情況

因此，如果採用定期刪除策略地話，伺服器必須根據情況，合理地設定刪除操作地執行時長和執行頻率。

reids過期鍵三種刪除策略

Redis 過期鍵刪除策略

過期鍵的刪除策略

redis過期鍵刪除策略

reids過期鍵三種刪除策略

Redis 過期鍵刪除策略

過期鍵的刪除策略

redis過期鍵刪除策略

相關推薦