線上服務(wù)為了限制用戶頻繁訪問敏感資源，通常會引入一種機(jī)制來限制這種訪問操作。其中一種常見的方案就是為每個用戶的訪問做一次時間戳，同一個用戶再次訪問對應(yīng)資源時，檢查當(dāng)前時間和已經(jīng)記錄的時間戳的差值 -- 如果此差值小于我們定義的超時時間，此次訪問被判定為頻繁訪問。

我們在某系統(tǒng)的實(shí)現(xiàn)中便采用了此種機(jī)制，限定用戶在 1s內(nèi)不能連續(xù)訪問2次，配合Memcache，實(shí)現(xiàn)起來非常簡單。 核心代碼如下：

publicbooleanisOutOfTime(Stringkey){

returnmemCachedClient.add(key,"abc",newDate(System.currentTimeMillis()+1000));

}

問題

一切看起來很順利，直到有一天線上報(bào)錯資源在100ms內(nèi)被訪問兩次。也就是說，同一個用戶的超時鍵被設(shè)置為1s以后，100ms再次去檢查居然鍵過期了。 什么鬼？邏輯上無懈可擊的代碼怎么可能會有漏洞？先不管那些，復(fù)現(xiàn)再說。

代碼簡單粗暴，就是啟5個線程，每個線程連續(xù)嘗試過濾某個鍵十萬次。

運(yùn)行上述代碼，每次都有很多鍵被判定為過期。充分分析整個流程，定位可能的問題原因：

后臺業(yè)務(wù)服務(wù)器與Memcache服務(wù)器時鐘不同步。Memcache的過期時間是一個時間戳，而不是相對時間偏移量，所以如果Memcache客戶端和服務(wù)器有時間差的話，比如客戶端的時間比服務(wù)器時間慢1s，那么客戶端設(shè)置的過期時間（它當(dāng)前的時間 + 1000ms）在服務(wù)器看來卻已經(jīng)過期了。

Memcache的鍵清理機(jī)制導(dǎo)致。在極端情況下（比如說Memcache被分配的內(nèi)存不夠用了），Memcache會清理一些鍵值對，即使這些鍵還沒有過期。

但是以上兩個原因中，時鐘不同步的原因很快被排除了。因?yàn)閺娜罩痉治鰜砜?，相?dāng)一部分頻繁請求是被攔截下來的，如果時鐘不同步，應(yīng)該有相當(dāng)比例的頻繁請求被放過才對。并且跟運(yùn)維確認(rèn)，線上的服務(wù)器都開啟了時鐘同步功能，兩個服務(wù)器的時鐘差不會超過10ms。

現(xiàn)在看來只有內(nèi)存清理機(jī)制這一個原因了。研究了下Memcache的鍵清理機(jī)制，總結(jié)如下：

當(dāng)有新數(shù)據(jù)需要存儲的時候，Memcache會先看數(shù)據(jù)大小對應(yīng)的Slab是否有空閑Item，如果有，將數(shù)據(jù)存入Item，同時更新LRU表。

如果沒有空閑Item，Memcache會嘗試去看對應(yīng)Slab是否有過期鍵。如果有，清空過期鍵，將數(shù)據(jù)存入新的Item，同時更新LRU表。

如果沒有過期鍵，Memcache會嘗試申請一個新的Slab，如果申請成功，將數(shù)據(jù)存入新Slab對應(yīng)的Item，同時更新LRU表。

如果申請失敗，并且Memcache配置了強(qiáng)制淘汰機(jī)制，會將LRU鏈表尾部的Item強(qiáng)制清空，并存入新Item，同時更新LRU表。

總體看下來，強(qiáng)制淘汰的觸發(fā)條件還是很苛刻的，并且具體的實(shí)現(xiàn)中，LRU鏈表分為Hot，Warm，Cold三個區(qū)域，新加入的數(shù)據(jù)會在Hot區(qū)，等Hot區(qū)滿了，較早的數(shù)據(jù)才會被降級到其他區(qū)。也就是說，假設(shè)存入數(shù)據(jù)為大小為100B，對應(yīng)Slab在Memcache服務(wù)器上只有一個（一般會有很多），那么此Slab中可用Item數(shù)量約為10000個。在這種情況下，如果要觸發(fā)剛剛存入100ms的未過期鍵被強(qiáng)制清理的話，需要在100ms內(nèi)有超過10000條100B左右大小的數(shù)據(jù)寫入Memcache。在測試環(huán)境幾乎不可能。但是這是一個公共的Memcache，誰知道呢？所以需要排除一下這個情況。

診斷

本地起一個虛擬機(jī)，裝個Memcache，順便打開日志打?。ū緛淼哪康氖菫榱丝吹芥I淘汰日志）。如果是強(qiáng)制淘汰機(jī)制引起，那在只有一個client的本地Memcache上，應(yīng)該就不會出現(xiàn)這個問題（測試代碼可以控制鍵數(shù)量和寫入速度），但是不幸的是，在這個空的Memcache上也出現(xiàn)了同樣的現(xiàn)象 -- 這直接排除了此現(xiàn)象是由強(qiáng)制淘汰機(jī)制導(dǎo)致的的可能性。

在本地虛擬機(jī)啟動的Memcache打印的日志中，發(fā)現(xiàn)了一個現(xiàn)象：所有時間戳都是類似于這樣的格式：1527001620，有點(diǎn)奇怪，比毫秒時間戳短。去查了一下源碼，果然被猜中：

而rel_time_t的定義為：

typedefunsignedintrel_time_t;

毫無疑問，Memcache的時間是用秒計(jì)算而不是毫秒。我們使用的客戶端接口方法：

publicbooleanadd(Stringkey,Objectvalue,Dateexpiry);

非常具有誤導(dǎo)性，因?yàn)镈ate是精確到毫秒的，這也使我們一直理所當(dāng)然地以為Memcache提供毫秒精度的過期時間校驗(yàn)，然而這是不對的。

原因

至此，問題的原因就很明朗了，Memcache的過期判斷代碼如下：

最重要的一句是：

it->exptime<=?current_time??

即：過期檢測中，當(dāng)前時間與過期時間相等即被判定為過期。 在這個前提下，當(dāng)如下情況發(fā)生時就會偶現(xiàn)線上的現(xiàn)象。

第一個請求，當(dāng)前時間××××01900 ，計(jì)算出的過期時間是××××02900（+1000ms） → 存入的過期時間是××××02

第二次請求，當(dāng)前時間××××02000，計(jì)算出的過期時間是××××03000（+1000ms） → 請求時，服務(wù)器判斷鍵過期（鍵過期時間 ××××02，當(dāng)前時間××××02） 此次請求add成功。

第一次請求和第二次請求僅隔100ms。

事實(shí)上，如果過期時間設(shè)置為1000ms，Memcache能幫我們隨機(jī)過濾0 ～ 1000ms內(nèi)的請求。頻繁請求是否被過濾依賴于最后一次成功請求的時間。

總結(jié)

使用Memcache的add方法做過期判斷時需要注意以下三點(diǎn)：

Memcache客戶端與服務(wù)器時間要同步；

內(nèi)存被強(qiáng)制淘汰的可能性極低，除非過期時間比較長，Memcache內(nèi)存吃緊時，需要關(guān)注此問題；

過期時間精度為秒。