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

我們在某系統的實現中便采用了此種機制，限定用戶在 1s內不能連續訪問2次，配合Memcache，實現起來非常簡單。 核心代碼如下：

publicbooleanisOutOfTime(Stringkey){

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

}

問題

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

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

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

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

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

但是以上兩個原因中，時鐘不同步的原因很快被排除了。因為從日志分析來看，相當一部分頻繁請求是被攔截下來的，如果時鐘不同步，應該有相當比例的頻繁請求被放過才對。并且跟運維確認，線上的服務器都開啟了時鐘同步功能，兩個服務器的時鐘差不會超過10ms。

現在看來只有內存清理機制這一個原因了。研究了下Memcache的鍵清理機制，總結如下：

當有新數據需要存儲的時候，Memcache會先看數據大小對應的Slab是否有空閑Item，如果有，將數據存入Item，同時更新LRU表。

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

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

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

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

診斷

本地起一個虛擬機，裝個Memcache，順便打開日志打印（本來的目的是為了看到鍵淘汰日志）。如果是強制淘汰機制引起，那在只有一個client的本地Memcache上，應該就不會出現這個問題（測試代碼可以控制鍵數量和寫入速度），但是不幸的是，在這個空的Memcache上也出現了同樣的現象 -- 這直接排除了此現象是由強制淘汰機制導致的的可能性。

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

而rel_time_t的定義為：

typedefunsignedintrel_time_t;

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

publicbooleanadd(Stringkey,Objectvalue,Dateexpiry);

非常具有誤導性，因為Date是精確到毫秒的，這也使我們一直理所當然地以為Memcache提供毫秒精度的過期時間校驗，然而這是不對的。

原因

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

最重要的一句是：

it->exptime<=?current_time??

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

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

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

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

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

總結

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

Memcache客戶端與服務器時間要同步；

內存被強制淘汰的可能性極低，除非過期時間比較長，Memcache內存吃緊時，需要關注此問題；

過期時間精度為秒。