色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線(xiàn)課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Memcache做頻率限制引發(fā)的問(wèn)題分析

電子工程師 ? 來(lái)源:網(wǎng)絡(luò)整理 ? 作者:工程師李察 ? 2018-09-08 10:18 ? 次閱讀

線(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í)間精度為秒。

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 服務(wù)器
    +關(guān)注

    關(guān)注

    12

    文章

    9123

    瀏覽量

    85329
  • Memcached
    +關(guān)注

    關(guān)注

    0

    文章

    13

    瀏覽量

    7017
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    為什么DCM會(huì)限制輸出頻率

    親愛(ài)的專(zhuān)家:在我的項(xiàng)目中,我需要使用幾個(gè)頻率,例如.2.048M,2.048 * 6M,512k,64k,8k。但我發(fā)現(xiàn)DCM限制了輸出頻率。我想知道為什么限制,我該怎么辦。非常感謝
    發(fā)表于 05-10 13:43

    memcache源碼實(shí)驗(yàn)步驟

    memcache源碼安裝及測(cè)試
    發(fā)表于 07-01 16:46

    Mac上memcache的安裝配置方法

    Mac上memcache的安裝配置
    發(fā)表于 07-13 15:33

    示波器實(shí)現(xiàn)頻率分析的方法

    研究領(lǐng)域和行業(yè)的最常用的儀器。  但是示波器能夠頻率分析是近年來(lái)才實(shí)現(xiàn)的。隨著數(shù)字信號(hào)處理技術(shù)的發(fā)展、算法技術(shù)改進(jìn)以及集成電路規(guī)模不斷按摩爾定律的指數(shù)級(jí)增長(zhǎng)等相關(guān)條件的成熟,研發(fā)工程師就把快速傅立葉
    發(fā)表于 09-04 17:28

    memcache主線(xiàn)程和工人線(xiàn)程進(jìn)行通信的設(shè)計(jì)實(shí)現(xiàn)

    1、memcache多線(xiàn)程模型memcache 是采用單進(jìn)程多線(xiàn)程模型,內(nèi)部使用 lib 事件庫(kù)來(lái)處理網(wǎng)絡(luò)請(qǐng)求。其工作是主線(xiàn)程負(fù)責(zé)接受的客戶(hù)端請(qǐng)求,然后輪詢(xún)模式新任務(wù)模式獲取連接工作人員的新線(xiàn)
    發(fā)表于 06-23 16:46

    Minitab柏拉圖分析

    Minitab柏拉圖分析:
    發(fā)表于 08-17 08:48 ?52次下載
    Minitab<b class='flag-5'>做</b>柏拉圖<b class='flag-5'>分析</b>

    CPU降低頻率或保持最大頻率(不超頻)_如何手動(dòng)給筆記本CPU限制頻率

    處理器最大頻率不能隨便設(shè)置,因?yàn)镃PU超頻時(shí),產(chǎn)生大量熱量,容易燒壞設(shè)備或出現(xiàn)故障,我就是保持CPU的最大頻率,不超率。當(dāng)CPU滿(mǎn)載運(yùn)行以至于溫度飆升時(shí)怎么手動(dòng)給筆記本CPU限制
    發(fā)表于 01-15 11:34 ?17.9w次閱讀

    redis和mongodb數(shù)據(jù)庫(kù)對(duì)比_redis、memcache、mongoDB 對(duì)比

    本文是對(duì)redis和mongodb數(shù)據(jù)庫(kù)對(duì)比分析。以及redis、memcache、mongoDB 區(qū)別對(duì)比。MongoDB和Redis都是NoSQL,采用結(jié)構(gòu)型數(shù)據(jù)存儲(chǔ)。二者在使用場(chǎng)景中,存在一定
    發(fā)表于 02-07 08:45 ?4253次閱讀
    redis和mongodb數(shù)據(jù)庫(kù)對(duì)比_redis、<b class='flag-5'>memcache</b>、mongoDB 對(duì)比

    redis、memcache原理對(duì)比

    redis、memcache原理對(duì)比。Memcached和Redis都能很好的滿(mǎn)足解決我們的問(wèn)題,它們性能都很高,總的來(lái)說(shuō),可以把Redis理解為是對(duì)Memcached的拓展,是更加重量級(jí)的實(shí)現(xiàn),提供了更多更強(qiáng)大的功能。
    的頭像 發(fā)表于 02-09 15:31 ?3429次閱讀
    redis、<b class='flag-5'>memcache</b>原理對(duì)比

    Memcache系統(tǒng)中有哪些常用的命令?

    Memcache是一個(gè)高性能的分布式內(nèi)存對(duì)象緩存系統(tǒng),用于動(dòng)態(tài)Web應(yīng)用以減輕數(shù)據(jù)庫(kù)負(fù)載。它通過(guò)在內(nèi)存中緩存數(shù)據(jù)和對(duì)象來(lái)減少讀取數(shù)據(jù)庫(kù)的次數(shù),從而提高動(dòng)態(tài)、數(shù)據(jù)庫(kù)驅(qū)動(dòng)網(wǎng)站的速度。Memcache
    發(fā)表于 04-03 15:09 ?2次下載

    IBM將內(nèi)存驅(qū)動(dòng)到uDepot!Memcache的問(wèn)題

    IBM還使用兩個(gè)Intel Optane 3D XPoint驅(qū)動(dòng)器(Intel P4800X 375GB)實(shí)現(xiàn)了uDepot,并將其與DRAM和閃存Memcache實(shí)施進(jìn)行了比較,再次使用memaslap測(cè)試。該公司比較了五種備選的memcache實(shí)現(xiàn)
    的頭像 發(fā)表于 01-18 14:25 ?3284次閱讀
    IBM將內(nèi)存驅(qū)動(dòng)到uDepot!<b class='flag-5'>Memcache</b>的問(wèn)題

    ADV7xx限制MCLK輸出頻率

    ADV7xx限制MCLK輸出頻率
    發(fā)表于 05-16 10:53 ?5次下載
    ADV7xx<b class='flag-5'>限制</b>MCLK輸出<b class='flag-5'>頻率</b>

    Memcache系統(tǒng)常用命令講解

    Memcache系統(tǒng)常用命令講解(無(wú)線(xiàn)電源技術(shù)商業(yè)計(jì)劃書(shū))-該文檔為Memcache系統(tǒng)常用命令講解文檔,是一份還算不錯(cuò)的參考文檔,感興趣的可以下載看看,,,,,,,,,,,,,,,,
    發(fā)表于 09-28 11:27 ?5次下載
    <b class='flag-5'>Memcache</b>系統(tǒng)常用命令講解

    windows-redis-memcahed redis和memcache集成快速使用包

    ./oschina_soft/gitee-win-redis-memcache.zip
    發(fā)表于 06-23 10:09 ?2次下載
    windows-redis-memcahed redis和<b class='flag-5'>memcache</b>集成快速使用包

    信號(hào)分析設(shè)備可分析頻率低于磁帶頻率

    本文主要介紹了信號(hào)分析設(shè)備的基本原理、類(lèi)型和應(yīng)用。特別關(guān)注了信號(hào)分析設(shè)備在分析低于磁帶頻率的信號(hào)時(shí)的性能和限制。 引言 信號(hào)
    的頭像 發(fā)表于 06-03 10:52 ?412次閱讀
    主站蜘蛛池模板: 亚洲精品在线看| 动漫女生的逼| 好姑娘BD高清在线观看免费| 欧美成 人 网 站 免费| 狠狠色在在线视频观看| 奇米狠狠干| 欧美国产精品主播一区| 欧美MV日韩MV国产网站| 性生片30分钟| 99热久久这里只有精品视频| 国产精品一区二区AV交换| 美女被爆羞羞天美传媒| 无套内射CHINESEHD熟女| 511麻豆视传媒精品AV| 国产精品美女WWW爽爽爽视频| 国产成人在线免费观看| 毛篇片在线观看| 久久欧洲视频| 色综合久久久久久| 啊好深啊别拔就射在里面| 酒色.com| 亚洲伊人久久网| 和I儿媳妇激情| 新影音先锋男人色资源网| 姑娘日本大全免费观看版中文翻译| 男人一进一出桶女人视频| 中文国产成人精品久久免费| 后式大肥臀国产在线| 亚洲成人免费在线| 国产精品禁18久久久夂久| 色婷婷AV99XX| 粉嫩自拍 偷拍 亚洲| 人妻免费久久久久久久了| GOGOGO高清免费播放| 男生在床上脱美女 胸| 13一18TV处流血TV| 久久久无码精品亚洲日韩按摩| 亚洲精品无码久久久久A片| 很黄很色60分钟在线观看| 亚洲合集综合久久性色| 国产午夜精品理论片|