背景

線上熱點(diǎn)數(shù)據(jù)幾乎都存放在memcached里，采用的經(jīng)典方案，優(yōu)先從memcached獲取數(shù)據(jù)，如果獲取失敗，再從MySQL獲取，同時(shí)回填memcached。隨著業(yè)務(wù)的飛速增長，數(shù)據(jù)量已經(jīng)超過了memcached設(shè)置的最大內(nèi)存，因?yàn)槌霈F(xiàn)了內(nèi)存置換出的情況，往往2天前的熱點(diǎn)數(shù)據(jù)會(huì)被喚出，這也很正常。
因?yàn)樾滦枨螅彺嬷行枰娣判碌臄?shù)據(jù)。但是實(shí)際測試發(fā)現(xiàn)，緩存中的數(shù)據(jù)幾分鐘就會(huì)被失效，導(dǎo)致MySQL壓力很大。
為什么同一個(gè)memcached的數(shù)據(jù)，有的緩存（后面簡稱為舊數(shù)據(jù)）要2天才會(huì)被置換出，有的緩存（后面簡稱新數(shù)據(jù)）幾分鐘就會(huì)被換出？

分析

首先分析新舊數(shù)據(jù)的不同：
1，key肯定不同
2，value大小上，舊數(shù)據(jù)value較大，新數(shù)據(jù)value很小
memcached是按照slabs作為內(nèi)存單元來分配。新舊數(shù)據(jù)value差異較大，肯定位于不同的chunk里面。考慮到memcached內(nèi)存已經(jīng)占滿，會(huì)不停置換內(nèi)存。為什么總是新數(shù)據(jù)被置換出來，而舊數(shù)據(jù)不容易被置換呢？只能去看memcached的代碼找尋答案。
主要代碼位于memcached\items.c的do_item_alloc。參考這里，核心代碼摘錄如下：

item *do_item_alloc(char *key, const size_t nkey, const int flags,
                    const rel_time_t exptime, const int nbytes,
                    const uint32_t cur_hv)
{
  //.....
   /* Expired or flushed */
        if ((search->exptime != 0 && search->exptime < current_time)
            || (search->time <= oldest_live && oldest_live <= current_time)) {
            itemstats[id].reclaimed++;
            if ((search->it_flags & ITEM_FETCHED) == 0) {
                itemstats[id].expired_unfetched++;
            }
            it = search;
            slabs_adjust_mem_requested(it->slabs_clsid, ITEM_ntotal(it), ntotal);
            do_item_unlink_nolock(it, hv);
            /* Initialize the item block: */
            it->slabs_clsid = 0;
        } else if ((it = slabs_alloc(ntotal, id)) == NULL) {
            tried_alloc = 1;
            if (settings.evict_to_free == 0) {
                itemstats[id].outofmemory++;
            } else {
                itemstats[id].evicted++;
                itemstats[id].evicted_time = current_time - search->time;
                if (search->exptime != 0)
                    itemstats[id].evicted_nonzero++;
                if ((search->it_flags & ITEM_FETCHED) == 0) {
                    itemstats[id].evicted_unfetched++;
                }
                it = search;
                slabs_adjust_mem_requested(it->slabs_clsid, ITEM_ntotal(it), ntotal);
                do_item_unlink_nolock(it, hv);
                /* Initialize the item block: */
                it->slabs_clsid = 0;
                //.....
      }
  }
}

1, 首先從LRU隊(duì)列中尋找是否有過期的item可用（代碼7-17行）。需要說明的是，這里的LRU隊(duì)列是每一chunk一個(gè)隊(duì)列，而不是全局統(tǒng)一一個(gè)。
2，如果LRU沒有過期數(shù)據(jù)，嘗試初始化一個(gè)新的slab（代碼18行），并分配給該chunk使用。
3，如果第二步失敗（比如內(nèi)存不夠用了），則只能從LRU隊(duì)列中淘汰最舊未使用的item了（代碼23-34行）。
原因到此基本查明了，緩存數(shù)據(jù)的過期時(shí)間都沒有設(shè)置，因此默認(rèn)就是30天。這樣當(dāng)內(nèi)存寫滿的情況下，分配一個(gè)item，前兩步都不會(huì)滿足，走到第三步。
對于舊數(shù)據(jù)，因?yàn)榕芰撕芫?，該chunk已經(jīng)占用了很多的slabs，所以通過LRU置換，問題并不大。
對于新數(shù)據(jù)，因?yàn)関alue大小差異較大，自然用的是一個(gè)沒多少slabs的chunk, 通過LRU置換，就會(huì)出現(xiàn)問題，導(dǎo)致頻繁被置換。
可以想到，如果這時(shí)候重啟了memcached，這樣新舊數(shù)據(jù)會(huì)比較公平，一段時(shí)間后都會(huì)分配差不多的item（假設(shè)新舊數(shù)據(jù)使用頻率差不多），這樣LRU換出的話，問題也不大。

解決

1，重啟memcached，解決這種新舊數(shù)據(jù)不公平的情況。
2，分配更大的memcached，避免出現(xiàn)換出。

后續(xù)

1，memcached可以使用stats 看evictions 的數(shù)據(jù)，如果不為0，說明此時(shí)memcached分配內(nèi)存出現(xiàn)了換出。
2，如果數(shù)據(jù)使用頻率差異很大，還是會(huì)發(fā)生這種情況。這時(shí)候就會(huì)麻煩一些，可以考慮分不同的memcached存儲(chǔ)，或者預(yù)先用假數(shù)據(jù)預(yù)熱緩存，目的就是占住LRU的位置。

轉(zhuǎn)載地址

為了防止作者不再維護(hù)該頁面，特地轉(zhuǎn)載留存，原著鏈接：Memcached過期策略問題追查