一個資源根據(jù)其大小可能會存在多個存儲對象中。如果足夠小（連同doc結(jié)構(gòu)的大小小于一個fragment的size），連同這個資源的meta信息一起存儲在一個doc中。如果比較大，第一個存儲對象保存資源的meta信息，后面跟著若干個fragment存著資源的content。這里討論小文件讀行為，并且內(nèi)存命中，在資源第二次命中的時候才有可能是內(nèi)存命中。整個流程在主狀態(tài)機(jī)流程的入口函數(shù)是Cache::open_read，正流程如下：

Cache::open_read: 首先需要計(jì)算的到vol，因?yàn)樾枰蕾Y源在哪個vol上才能確定是否存在，每個vol都是獨(dú)立存在的。獲取鎖之后運(yùn)行了dir_probe函數(shù)，確定了緩存查詢的結(jié)果。獲取了dir，對CacheVC對象的key和dir進(jìn)行了初始化。生成一個CacheVC對象，之后的操作都是這個CacheVC對象是事兒了。設(shè)置回調(diào)函數(shù)為Cache::openReadStartHead，設(shè)置完回調(diào)函數(shù)會執(zhí)行do_read_call，最終do_read_call返回了EVENT_RETURN，執(zhí)行了事件回調(diào)函數(shù)，就是剛剛設(shè)置的Cache::openReadStartHead。

dir_probe: 通過md5值計(jì)算得到資源所在的segemnt和bucket，進(jìn)而得到目標(biāo)dir，如果dir是否“正確”，如果正確就認(rèn)為命中了。

CacheVC::do_read_call:?初始化doc_pos為0。解析dir，獲取fragment大概大小(dir_approx_size)。決定是否應(yīng)該存在于ssd中(dir_inssd)，如果已經(jīng)是從ssd中讀了，就肯定不寫了。每個vol都會對應(yīng)自己的ssd，每個vol都會維護(hù)一些歷史數(shù)據(jù)用來判斷熱度相關(guān)的數(shù)據(jù)。最終執(zhí)行CacheVC::handleRead，最終返回了EVENT_RETURN。

CacheVC::handleRead: 獲取偏移量(dir_get_offset)。 在內(nèi)存中查詢(vol->ram_cache->get函數(shù)會根據(jù)records.config中的配置項(xiàng)proxy.config.cache.ram_cache.algorithm指向不同的函數(shù))。假設(shè)內(nèi)存查詢函數(shù)為RamCacheLRU::get，詳見下面解析。內(nèi)存命中的話在這個函數(shù)里面會將內(nèi)容放倒buf中，進(jìn)而獲取到了doc。

RamCacheLRU::get: 判斷是否在內(nèi)存中命中，如果命中了，在lru隊(duì)列中刪除并且在頭部重新插入。

CacheVC::openReadStartHead: 每次讀操作都會執(zhí)行一次，獲取這個資源相關(guān)的信息，根據(jù)buf是否為空判斷是否命中。確定一個alternate，通過判斷alternate的key是否就是doc的key來判斷這個alternate是不是要找的那個。如果是的話判斷是不是single fragment，如果滿足len = heln + total_len + 72，認(rèn)為是小文件。獲取doc_pos，即為doc的大小與整個資源的metadata的大小的和。獲取next key（對于小文件沒必要，但是也執(zhí)行了），執(zhí)行begin_read，這個函數(shù)主要判斷了是否需要evacuate，由于小文件都會存在一個fragment，而此時已經(jīng)都到了內(nèi)存中，所以不需要考慮evacuate問題。最后將回調(diào)函數(shù)設(shè)置為 CacheVC::openReadMain，并且執(zhí)行緩存主狀態(tài)機(jī)事件回調(diào)函數(shù)?HttpCacheSM::state_cache_open_read，傳遞的參數(shù)是 CACHE_EVENT_OPEN_READ。

轉(zhuǎn)載于:https://blog.51cto.com/11490450/1861921

總結(jié)

以上是生活随笔為你收集整理的ATS读小文件（内存命中）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。