線(xiàn)上服務(wù)為了限制用戶(hù)頻繁訪問(wèn)敏感資源,通常會(huì)引入一種機(jī)制來(lái)限制這種訪問(wèn)操作。其中一種常見(jiàn)的方案就是為每個(gè)用戶(hù)的訪問(wèn)做一次時(shí)間戳,同一個(gè)用戶(hù)再次訪問(wèn)對(duì)應(yīng)資源時(shí),檢查當(dāng)前時(shí)間和已經(jīng)記錄的時(shí)間戳的差值 -- 如果此差值小于我們定義的超時(shí)時(shí)間,此次訪問(wèn)被判定為頻繁訪問(wèn)。
我們?cè)谀诚到y(tǒng)的實(shí)現(xiàn)中便采用了此種機(jī)制,限定用戶(hù)在 1s內(nèi)不能連續(xù)訪問(wèn)2次,配合Memcache,實(shí)現(xiàn)起來(lái)非常簡(jiǎn)單。 核心代碼如下:
publicbooleanisOutOfTime(Stringkey){
returnmemCachedClient.add(key,"abc",newDate(System.currentTimeMillis()+1000));
}
問(wèn)題
一切看起來(lái)很順利,直到有一天線(xiàn)上報(bào)錯(cuò)資源在100ms內(nèi)被訪問(wèn)兩次。也就是說(shuō),同一個(gè)用戶(hù)的超時(shí)鍵被設(shè)置為1s以后,100ms再次去檢查居然鍵過(guò)期了。 什么鬼?邏輯上無(wú)懈可擊的代碼怎么可能會(huì)有漏洞?先不管那些,復(fù)現(xiàn)再說(shuō)。
代碼簡(jiǎn)單粗暴,就是啟5個(gè)線(xiàn)程,每個(gè)線(xiàn)程連續(xù)嘗試過(guò)濾某個(gè)鍵十萬(wàn)次。
運(yùn)行上述代碼,每次都有很多鍵被判定為過(guò)期。充分分析整個(gè)流程,定位可能的問(wèn)題原因:
后臺(tái)業(yè)務(wù)服務(wù)器與Memcache服務(wù)器時(shí)鐘不同步。Memcache的過(guò)期時(shí)間是一個(gè)時(shí)間戳,而不是相對(duì)時(shí)間偏移量,所以如果Memcache客戶(hù)端和服務(wù)器有時(shí)間差的話(huà),比如客戶(hù)端的時(shí)間比服務(wù)器時(shí)間慢1s,那么客戶(hù)端設(shè)置的過(guò)期時(shí)間(它當(dāng)前的時(shí)間 + 1000ms)在服務(wù)器看來(lái)卻已經(jīng)過(guò)期了。
Memcache的鍵清理機(jī)制導(dǎo)致。在極端情況下(比如說(shuō)Memcache被分配的內(nèi)存不夠用了),Memcache會(huì)清理一些鍵值對(duì),即使這些鍵還沒(méi)有過(guò)期。
但是以上兩個(gè)原因中,時(shí)鐘不同步的原因很快被排除了。因?yàn)閺娜罩痉治鰜?lái)看,相當(dāng)一部分頻繁請(qǐng)求是被攔截下來(lái)的,如果時(shí)鐘不同步,應(yīng)該有相當(dāng)比例的頻繁請(qǐng)求被放過(guò)才對(duì)。并且跟運(yùn)維確認(rèn),線(xiàn)上的服務(wù)器都開(kāi)啟了時(shí)鐘同步功能,兩個(gè)服務(wù)器的時(shí)鐘差不會(huì)超過(guò)10ms。
現(xiàn)在看來(lái)只有內(nèi)存清理機(jī)制這一個(gè)原因了。研究了下Memcache的鍵清理機(jī)制,總結(jié)如下:
當(dāng)有新數(shù)據(jù)需要存儲(chǔ)的時(shí)候,Memcache會(huì)先看數(shù)據(jù)大小對(duì)應(yīng)的Slab是否有空閑Item,如果有,將數(shù)據(jù)存入Item,同時(shí)更新LRU表。
如果沒(méi)有空閑Item,Memcache會(huì)嘗試去看對(duì)應(yīng)Slab是否有過(guò)期鍵。如果有,清空過(guò)期鍵,將數(shù)據(jù)存入新的Item,同時(shí)更新LRU表。
如果沒(méi)有過(guò)期鍵,Memcache會(huì)嘗試申請(qǐng)一個(gè)新的Slab,如果申請(qǐng)成功,將數(shù)據(jù)存入新Slab對(duì)應(yīng)的Item,同時(shí)更新LRU表。
如果申請(qǐng)失敗,并且Memcache配置了強(qiáng)制淘汰機(jī)制,會(huì)將LRU鏈表尾部的Item強(qiáng)制清空,并存入新Item,同時(shí)更新LRU表。
總體看下來(lái),強(qiáng)制淘汰的觸發(fā)條件還是很苛刻的,并且具體的實(shí)現(xiàn)中,LRU鏈表分為Hot,Warm,Cold三個(gè)區(qū)域,新加入的數(shù)據(jù)會(huì)在Hot區(qū),等Hot區(qū)滿(mǎn)了,較早的數(shù)據(jù)才會(huì)被降級(jí)到其他區(qū)。也就是說(shuō),假設(shè)存入數(shù)據(jù)為大小為100B,對(duì)應(yīng)Slab在Memcache服務(wù)器上只有一個(gè)(一般會(huì)有很多),那么此Slab中可用Item數(shù)量約為10000個(gè)。在這種情況下,如果要觸發(fā)剛剛存入100ms的未過(guò)期鍵被強(qiáng)制清理的話(huà),需要在100ms內(nèi)有超過(guò)10000條100B左右大小的數(shù)據(jù)寫(xiě)入Memcache。在測(cè)試環(huán)境幾乎不可能。但是這是一個(gè)公共的Memcache,誰(shuí)知道呢?所以需要排除一下這個(gè)情況。
診斷
本地起一個(gè)虛擬機(jī),裝個(gè)Memcache,順便打開(kāi)日志打印(本來(lái)的目的是為了看到鍵淘汰日志)。如果是強(qiáng)制淘汰機(jī)制引起,那在只有一個(gè)client的本地Memcache上,應(yīng)該就不會(huì)出現(xiàn)這個(gè)問(wèn)題(測(cè)試代碼可以控制鍵數(shù)量和寫(xiě)入速度),但是不幸的是,在這個(gè)空的Memcache上也出現(xiàn)了同樣的現(xiàn)象 -- 這直接排除了此現(xiàn)象是由強(qiáng)制淘汰機(jī)制導(dǎo)致的的可能性。
在本地虛擬機(jī)啟動(dòng)的Memcache打印的日志中,發(fā)現(xiàn)了一個(gè)現(xiàn)象:所有時(shí)間戳都是類(lèi)似于這樣的格式:1527001620,有點(diǎn)奇怪,比毫秒時(shí)間戳短。去查了一下源碼,果然被猜中:
而rel_time_t的定義為:
typedefunsignedintrel_time_t;
毫無(wú)疑問(wèn),Memcache的時(shí)間是用秒計(jì)算而不是毫秒。我們使用的客戶(hù)端接口方法:
publicbooleanadd(Stringkey,Objectvalue,Dateexpiry);
非常具有誤導(dǎo)性,因?yàn)镈ate是精確到毫秒的,這也使我們一直理所當(dāng)然地以為Memcache提供毫秒精度的過(guò)期時(shí)間校驗(yàn),然而這是不對(duì)的。
原因
至此,問(wèn)題的原因就很明朗了,Memcache的過(guò)期判斷代碼如下:
最重要的一句是:
it->exptime<=?current_time??
即:過(guò)期檢測(cè)中,當(dāng)前時(shí)間與過(guò)期時(shí)間相等即被判定為過(guò)期。 在這個(gè)前提下,當(dāng)如下情況發(fā)生時(shí)就會(huì)偶現(xiàn)線(xiàn)上的現(xiàn)象。
第一個(gè)請(qǐng)求,當(dāng)前時(shí)間××××01900 ,計(jì)算出的過(guò)期時(shí)間是××××02900(+1000ms) → 存入的過(guò)期時(shí)間是××××02
第二次請(qǐng)求,當(dāng)前時(shí)間××××02000,計(jì)算出的過(guò)期時(shí)間是××××03000(+1000ms) → 請(qǐng)求時(shí),服務(wù)器判斷鍵過(guò)期(鍵過(guò)期時(shí)間 ××××02,當(dāng)前時(shí)間××××02) 此次請(qǐng)求add成功。
第一次請(qǐng)求和第二次請(qǐng)求僅隔100ms。
事實(shí)上,如果過(guò)期時(shí)間設(shè)置為1000ms,Memcache能幫我們隨機(jī)過(guò)濾0 ~ 1000ms內(nèi)的請(qǐng)求。頻繁請(qǐng)求是否被過(guò)濾依賴(lài)于最后一次成功請(qǐng)求的時(shí)間。
總結(jié)
使用Memcache的add方法做過(guò)期判斷時(shí)需要注意以下三點(diǎn):
Memcache客戶(hù)端與服務(wù)器時(shí)間要同步;
內(nèi)存被強(qiáng)制淘汰的可能性極低,除非過(guò)期時(shí)間比較長(zhǎng),Memcache內(nèi)存吃緊時(shí),需要關(guān)注此問(wèn)題;
過(guò)期時(shí)間精度為秒。
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
9123瀏覽量
85329 -
Memcached
+關(guān)注
關(guān)注
0文章
13瀏覽量
7017
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論