在使用redis時,通常會設置一個過時時間,固然也有不設置過時時間的,也就是永久不過時。當設置了過時時間,redis是如何判斷是否過時,以及根據什麼策略來進行刪除的。redis
設置過時時間
expire key time(以秒爲單位) 這是最經常使用的方式
setex(String key, int seconds, String value) 字符串獨有的方式
除了字符串本身獨有設置過時時間的方法外,其餘方法都須要依靠expire方法來設置時間若是沒有設置時間,那緩存就是永不過時若是設置了過時時間,以後又想讓緩存永不過時,使用persist key數據庫
三種過時策略
定時刪除
在設置key的過時時間的同時,爲該key建立一個定時器,讓定時器在key的過時時間來臨時,對key進行刪除緩存
優勢:服務器
保證內存被儘快釋放
缺點:併發
若過時key不少,刪除這些key會佔用不少的CPU時間,在CPU時間緊張的狀況下,CPU不能把全部的時間用來作要緊的事兒,還須要去花時間刪除這些key
定時器的建立耗時,若爲每個設置過時時間的key建立一個定時器(將會有大量的定時器產生),性能影響嚴重
懶漢式式刪除
key過時的時候不刪除,每次經過key獲取值的時候去檢查是否過時,若過時,則刪除,返回null。memcached
優勢:性能
刪除操做只發生在經過key取值的時候發生,並且只刪除當前key,因此對CPU時間的佔用是比較少的,並且此時的刪除是已經到了非作不可的地步(若是此時還不刪除的話,咱們就會獲取到了已通過期的key了)
缺點:設計
若大量的key在超出超時時間後,好久一段時間內,都沒有被獲取過,那麼可能發生內存泄露(無用的垃圾佔用了大量的內存)
按期刪除
每隔一段時間執行一次刪除過時key操做內存
優勢:字符串
經過限制刪除操做的時長和頻率,來減小刪除操做對CPU時間的佔用--處理"定時刪除"的缺點
按期刪除過時key--處理"懶漢式刪除"的缺點
缺點:
在內存友好方面,不如"定時刪除"(會形成必定的內存佔用,可是沒有懶漢式那麼佔用內存)
在CPU時間友好方面,不如"懶漢式刪除"(會按期的去進行比較和刪除操做,cpu方面不如懶漢式,可是比定時好)
難點:
合理設置刪除操做的執行時長(每次刪除執行多長時間)和執行頻率(每隔多長時間作一次刪除)(這個要根據服務器運行狀況來定了),每次執行時間太長,或者執行頻率過高對cpu都是一種壓力。
每次進行按期刪除操做執行以後,須要記錄遍歷循環到了哪一個標誌位,以便下一次按期時間來時,從上次位置開始進行循環遍歷
說明:
memcached只是用了惰性刪除,而redis同時使用了惰性刪除與按期刪除,這也是兩者的一個不一樣點(能夠看作是redis優於memcached的一點);
對於懶漢式刪除而言,並非只有獲取key的時候纔會檢查key是否過時,在某些設置key的方法上也會檢查(eg.setnx key2 value2:該方法相似於memcached的add方法,若是設置的key2已經存在,那麼該方法返回false,什麼都不作;若是設置的key2不存在,那麼該方法設置緩存key2-value2。假設調用此方法的時候,發現redis中已經存在了key2,可是該key2已通過期了,若是此時不執行刪除操做的話,setnx方法將會直接返回false,也就是說此時並無從新設置key2-value2成功,因此對於必定要在setnx執行以前,對key2進行過時檢查)。
Redis採用的過時策略
懶漢式刪除+按期刪除
懶漢式刪除流程:
在進行get或setnx等操做時,先檢查key是否過時;
若過時,刪除key,而後執行相應操做;
若沒過時,直接執行相應操做;
按期刪除流程
簡單而言,對指定個數個庫的每個庫隨機刪除小於等於指定個數個過時key
遍歷每一個數據庫(就是redis.conf中配置的"database"數量,默認爲16)
檢查當前庫中的指定個數個key(默認是每一個庫檢查20個key,注意至關於該循環執行20次,循環體是下邊的描述)
若是當前庫中沒有一個key設置了過時時間,直接執行下一個庫的遍歷
隨機獲取一個設置了過時時間的key,檢查該key是否過時,若是過時,刪除key
判判定期刪除操做是否已經達到指定時長,若已經達到,直接退出按期刪除。
對於按期刪除,在程序中有一個全局變量currentdb來記錄下一個將要遍歷的庫,假設有16個庫,咱們這一次按期刪除遍歷了10個,那此時的currentdb就是11,下一次按期刪除就從第11個庫開始遍歷,假設currentdb等於15了,那麼以後遍歷就再從0號庫開始(此時currentdb==0)
總結在實際中,若是咱們要本身設計過時策略,在使用懶漢式刪除+按期刪除時,控制時長和頻率這個尤其關鍵,須要結合服務器性能,已經併發量等狀況進行調整,以至最佳。