最近項目上出現(xiàn)了一個無法理解的BUG,用戶默認每天享有一定次數(shù)的權(quán)限,使用完畢則無法享用,第二天才能再繼續(xù)。本質(zhì)就是redis緩存過期嘛,讓它凌晨12點失效就好了。
但是問題發(fā)生了,它就是沒失效...深究其原因,竟是由于零界點沒處理好的鍋,服務(wù)器時間與request時間是有些許時間差的,key的expire到了一定數(shù)量處理也是需要時間噠,就這倆主因。加個存在判斷,失效給他提前個10秒留個準備就好了~
所以吸取教訓(xùn),好好了解一下這個失效機理,同時也提醒各位別范這種低級錯誤。
一。如何才能觸發(fā)key的失效?
除了調(diào)用PERSIST命令外,還有沒有其他情況會撤銷一個主鍵的失效時間?答案是肯定的。
1.在通過 DEL 命令刪除一個主鍵時
2.在一個設(shè)置了失效時間的主鍵被更新覆蓋時,該主鍵的失效時間也會被撤銷。
3.特殊的命令就是 RENAME,當(dāng)我們使用 RENAME 對一個主鍵進行重命名后,之前關(guān)聯(lián)的失效時間會自動傳遞給新的主鍵,但是如果一個主鍵是被RENAME所覆蓋的話(如主鍵 hello 可能會被命令 RENAME world hello 所覆蓋),這時被覆蓋主鍵的失效時間會被自動撤銷,而新的主鍵則繼續(xù)保持原來主鍵的特性。
注意,這里所說的是主鍵被更新覆蓋,而不是主鍵對應(yīng)的 Value 被更新覆蓋,因此 SET、MSET 或者是 GETSET 可能會導(dǎo)致主鍵被更新覆蓋,而像 INCR、DECR、LPUSH、HSET 等都是更新主鍵對應(yīng)的值,這類操作是不會觸碰主鍵的失效時間的。
二。Redis是如何管理和維護主鍵的
1).Redis的存儲結(jié)構(gòu)
typedef struct redisDb {
dict *dict;//存儲主鍵和值的映射
dict *expires;//存儲主鍵和過期時間的映射
dict *blocking_keys;
dict *ready_keys;
dict *watched_keys;
int id;
} redisDb;
主要看前兩個結(jié)構(gòu)就好,
dict:用來維護一個 Redis 數(shù)據(jù)庫中包含的所有 Key-Value 對(其結(jié)構(gòu)可以理解為 dict[key]:value,即主鍵與值之間的映射)
expires:用于維護一個 Redis 數(shù)據(jù)庫中設(shè)置了失效時間的主鍵(其結(jié)構(gòu)可以理解為 expires[key]:timeout,即主鍵與失效時間的映射)。
設(shè)置了失效時間的主鍵和具體的失效時間全部都維護在 expires 這個字典表中
當(dāng)我們使用 EXPIRE、EXPIREAT、PEXPIRE 和 PEXPIREAT 命令設(shè)置一個主鍵的失效時間時,
Redis 首先到 dict 這個字典表中查找要設(shè)置的主鍵是否存在,如果存在就將這個主鍵和失效時間添加到 expires 這個字典表。
2).消極方法
1.expireIfNeeded函數(shù)
觸發(fā):這個函數(shù)在任何訪問數(shù)據(jù)的函數(shù)中都會被調(diào)用,Redis 在實現(xiàn) GET、MGET、HGET、LRANGE 等所有涉及到讀取數(shù)據(jù)的命令時都會調(diào)用它
意義:在讀取數(shù)據(jù)之前先檢查一下該key有沒有失效,如果失效了就刪除它。
2.propagateExpire函數(shù)(在上邊一個函數(shù)中調(diào)用) 主要函數(shù)
觸發(fā):執(zhí)行上一個函數(shù)時,它在其里邊
意義:用來在正式刪除失效主鍵之前廣播這個主鍵已經(jīng)失效的信息
操作:
(1).一個是發(fā)送到 AOF文件,將刪除失效主鍵的這一操作以 DEL Key 的標準命令格式記錄下來;
(2).發(fā)送到當(dāng)前 Redis 服務(wù)器的所有 Slave,同樣將刪除失效主鍵的這一操作以 DEL Key 的標準命令格式告知這些 Slave 刪除各自的失效主鍵。
以上我們了解了 Redis 是如何以一種消極的方式刪除失效主鍵的,但是僅僅通過這種方式顯然是不夠的,因為如果某些失效的主鍵遲遲等不到再次訪問的話,Redis 就永遠不會知道這些主鍵已經(jīng)失效,也就永遠也不會刪除它們了,這無疑會導(dǎo)致內(nèi)存空間的浪費。所以有了下邊的方法。
3).積極方法:(該方法利用 Redis 的時間事件來實現(xiàn),即每隔一段時間就中斷一下完成一些指定操作)
1.serverCron函數(shù):
觸發(fā):它在 Redis 服務(wù)器啟動時創(chuàng)建
作用:這個回調(diào)函數(shù)不僅要進行失效主鍵的檢查與刪除,還要進行統(tǒng)計信息的更新、客戶端連接超時的控制、BGSAVE 和 AOF 的觸發(fā)等等
2.activeExpireCycle函數(shù):
觸發(fā):執(zhí)行上一個函數(shù)時,它在其里邊每秒的執(zhí)行次數(shù)由宏定義 【REDIS_DEFAULT_HZ】 來指定,默認每秒鐘執(zhí)行10次。
操作:
a).遍歷處理 Redis 服務(wù)器中每個數(shù)據(jù)庫的 expires 字典表中,從中嘗試著隨機抽樣【REDIS_EXPIRELOOKUPS_PER_CRON】(默認 值為10)個設(shè)置了失效時間的主鍵,
b).檢查它們是否已經(jīng)失效并刪除掉失效的主鍵,
c).如果失效的主鍵個數(shù)占本次抽樣個數(shù)的比例超過25%,Redis 會認為當(dāng)前數(shù)據(jù)庫中的失效主鍵依然很多,所以它會繼續(xù)進行下一輪的隨機抽樣和刪除,
d).直到剛才的比例低于25%才停止對當(dāng)前數(shù)據(jù)庫的處理,轉(zhuǎn)向下一個數(shù)據(jù)庫。
其他:activeExpireCycle 函數(shù)避免失效主鍵刪除占用過多的CPU資源,所以其不會試圖一次性處理Redis中的所有數(shù)據(jù)庫,而是最多只處理 REDIS_DBCRON_DBS_PER_CALL(默認值為16)個庫,有處理時間上的限制
三。Memcached 刪除失效主鍵的方法與 Redis 有何異同?
首先,Memcached 在刪除失效主鍵時也是采用的消極方法,即 Memcached 內(nèi)部也不會監(jiān)視主鍵是否失效,而是在通過 Get 訪問主鍵時才會檢查其是否已經(jīng)失效。
其次,Memcached 與 Redis 在主鍵失效機制上的最大不同是,Memcached 不會像 Redis 那樣真正地去刪除失效的主鍵,而只是簡單地將失效主鍵占用的空間回收。這樣當(dāng)有新的數(shù)據(jù)寫入到系統(tǒng)中時,Memcached 會優(yōu)先使用那些失效主鍵的空間。如果失效主鍵的空間用光了,Memcached 還可以通過 LRU 機制來回收那些長期得不到訪問的空間,
因此 Memcached 并不需要像 Redis 中那樣的周期性刪除操作,這也是由 Memcached 使用的內(nèi)存管理機制決定的。同時,這里需要指出的是 Redis 在出現(xiàn) OOM 時同樣可以通過配置 maxmemory-policy 這個參數(shù)來決定是否采用 LRU 機制來回收內(nèi)存空間
四??偨Y(jié):
redis每秒執(zhí)行10次過期檢查,每次中,隨機從某個庫的expire表中抽取10個key,檢測他是否失效,若失效則刪除。當(dāng)失效比例超過1/4,本次重新執(zhí)行隨機抽取10key,不計入10次中的1次,直到這一秒的10次都執(zhí)行完。
問:
那么有人問了,萬一,萬一!失效的key做足夠的多,1秒的這10次都沒執(zhí)行完又到下一秒了,咋整?
答:
redis有檢測機制的,不會讓它把CPU拖死的:
a.每次處理數(shù)據(jù)庫個數(shù)的限制、
b.activeExpireCycle 函數(shù)在一秒鐘內(nèi)執(zhí)行次數(shù)的限制、
c.分配給 activeExpireCycle函數(shù)CPU時間的限制、
d.繼續(xù)刪除主鍵的失效主鍵數(shù)百分比的限制,Redis 已經(jīng)大大降低了主鍵失效機制對系統(tǒng)整體性能的影響,
所以由此也可得,設(shè)置失效時間的原則:盡可能避免在同一時間點的大批量key失效,它是需要處理時間的。
消極失效主要函數(shù).propagateExpire函數(shù):
void propagateExpire(redisDb *db, robj *key) {
robj *argv[2];
//shared.del是在Redis服務(wù)器啟動之初就已經(jīng)初始化好的一個常用Redis對象,即DEL命令
argv[0] = shared.del;
argv[1] = key;
incrRefCount(argv[0]);
incrRefCount(argv[1]);
//檢查Redis服務(wù)器是否開啟了AOF,如果開啟了就為失效主鍵記錄一條DEL日志
if (server.aof_state != REDIS_AOF_OFF)
feedAppendOnlyFile(server.delCommand,db->id,argv,2);
//檢查Redis服務(wù)器是否擁有Slave,如果是就向所有Slave發(fā)送DEL失效主鍵的命令,這就是
//上面expireIfNeeded函數(shù)中發(fā)現(xiàn)自己是Slave時無需主動刪除失效主鍵的原因了,因為它
//只需聽從Master發(fā)送過來的命令就OK了
if (listLength(server.slaves))
replicationFeedSlaves(server.slaves,db->id,argv,2);
decrRefCount(argv[0]);
decrRefCount(argv[1]);
}
積極失效主要函數(shù).activeExpireCycle函數(shù):
void activeExpireCycle(void) {
//因為每次調(diào)用activeExpireCycle函數(shù)不會一次性檢查所有Redis數(shù)據(jù)庫,所以需要記錄下
//每次函數(shù)調(diào)用處理的最后一個Redis數(shù)據(jù)庫的編號,這樣下次調(diào)用activeExpireCycle函數(shù)
//還可以從這個數(shù)據(jù)庫開始繼續(xù)處理,這就是current_db被聲明為static的原因,而另外一
//個變量timelimit_exit是為了記錄上一次調(diào)用activeExpireCycle函數(shù)的執(zhí)行時間是否達
//到時間限制了,所以也需要聲明為static
static unsigned int current_db = 0;
static int timelimit_exit = 0;
unsigned int j, iteration = 0;
//每次調(diào)用activeExpireCycle函數(shù)處理的Redis數(shù)據(jù)庫個數(shù)為REDIS_DBCRON_DBS_PER_CALL
unsigned int dbs_per_call = REDIS_DBCRON_DBS_PER_CALL;
long long start = ustime(), timelimit;
//如果當(dāng)前Redis服務(wù)器中的數(shù)據(jù)庫個數(shù)小于REDIS_DBCRON_DBS_PER_CALL,則處理全部數(shù)據(jù)庫,
//如果上一次調(diào)用activeExpireCycle函數(shù)的執(zhí)行時間達到了時間限制,說明失效主鍵較多,也
//會選擇處理全部數(shù)據(jù)庫
if (dbs_per_call > server.dbnum || timelimit_exit)
dbs_per_call = server.dbnum;
//執(zhí)行activeExpireCycle函數(shù)的最長時間(以微秒計),其中REDIS_EXPIRELOOKUPS_TIME_PERC
//是單位時間內(nèi)能夠分配給activeExpireCycle函數(shù)執(zhí)行的CPU時間比例,默認值為25,server.hz
//即為一秒內(nèi)activeExpireCycle的調(diào)用次數(shù),所以這個計算公式更明白的寫法應(yīng)該是這樣的,即
(1000000 * (REDIS_EXPIRELOOKUPS_TIME_PERC / 100)) / server.hz
timelimit = 1000000*REDIS_EXPIRELOOKUPS_TIME_PERC/server.hz/100;
timelimit_exit = 0;
if (timelimit = 0) timelimit = 1;
//遍歷處理每個Redis數(shù)據(jù)庫中的失效數(shù)據(jù)
for (j = 0; j dbs_per_call; j++) {
int expired;
redisDb *db = server.db+(current_db % server.dbnum);
//此處立刻就將current_db加一,這樣可以保證即使這次無法在時間限制內(nèi)刪除完所有當(dāng)前
//數(shù)據(jù)庫中的失效主鍵,下一次調(diào)用activeExpireCycle一樣會從下一個數(shù)據(jù)庫開始處理,
//從而保證每個數(shù)據(jù)庫都有被處理的機會
current_db++;
//開始處理當(dāng)前數(shù)據(jù)庫中的失效主鍵
do {
unsigned long num, slots;
long long now;
//如果expires字典表大小為0,說明該數(shù)據(jù)庫中沒有設(shè)置失效時間的主鍵,直接檢查下
//一數(shù)據(jù)庫
if ((num = dictSize(db->expires)) == 0) break;
slots = dictSlots(db->expires);
now = mstime();
//如果expires字典表不為空,但是其填充率不足1%,那么隨機選擇主鍵進行檢查的代價
//會很高,所以這里直接檢查下一數(shù)據(jù)庫
if (num slots > DICT_HT_INITIAL_SIZE
(num*100/slots 1)) break;
expired = 0;
//如果expires字典表中的entry個數(shù)不足以達到抽樣個數(shù),則選擇全部key作為抽樣樣本
if (num > REDIS_EXPIRELOOKUPS_PER_CRON)
num = REDIS_EXPIRELOOKUPS_PER_CRON;
while (num--) {
dictEntry *de;
long long t;
//隨機獲取一個設(shè)置了失效時間的主鍵,檢查其是否已經(jīng)失效
if ((de = dictGetRandomKey(db->expires)) == NULL) break;
t = dictGetSignedIntegerVal(de);
if (now > t) {
//發(fā)現(xiàn)該主鍵確實已經(jīng)失效,刪除該主鍵
sds key = dictGetKey(de);
robj *keyobj = createStringObject(key,sdslen(key));
//同樣要在刪除前廣播該主鍵的失效信息
propagateExpire(db,keyobj);
dbDelete(db,keyobj);
decrRefCount(keyobj);
expired++;
server.stat_expiredkeys++;
}
}
//每進行一次抽樣刪除后對iteration加一,每16次抽樣刪除后檢查本次執(zhí)行時間是否
//已經(jīng)達到時間限制,如果已達到時間限制,則記錄本次執(zhí)行達到時間限制并退出
iteration++;
if ((iteration 0xf) == 0
(ustime()-start) > timelimit)
{
timelimit_exit = 1;
return;
}
//如果失效的主鍵數(shù)占抽樣數(shù)的百分比大于25%,則繼續(xù)抽樣刪除過程
} while (expired > REDIS_EXPIRELOOKUPS_PER_CRON/4);
}
}
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
您可能感興趣的文章:- ThinkPHP框架中使用Memcached緩存數(shù)據(jù)的方法
- .NET Core中使用Redis與Memcached的序列化問題詳析
- CentOS 7.x安裝部署Memcached服務(wù)器的詳細方法
- java 使用memcached以及spring 配置memcached完整實例代碼
- 在Linux服務(wù)器上安裝 memcached的基本操作
- PHP內(nèi)存緩存功能memcached示例
- Laravel使用memcached緩存對文章增刪改查進行優(yōu)化的方法
- Laravel Memcached緩存驅(qū)動的配置與應(yīng)用方法分析
- 解決 .NET Core 中 GetHostAddressesAsync 引起的 EnyimMemcached 死鎖問題
- 在windows系統(tǒng)下如何安裝memcached的講解