ATS如何進(jìn)行緩存策略增加動態(tài)服務(wù)吞吐量

今天給大家介紹一下ATS如何進(jìn)行緩存策略增加動態(tài)服務(wù)吞吐量。，文章的內(nèi)容小編覺得不錯(cuò)，現(xiàn)在給大家分享一下，覺得有需要的朋友可以了解一下，希望對大家有所幫助，下面跟著小編的思路一起來閱讀吧。

先看一下策略調(diào)整后瞬間的流量圖：

    為了提高用戶體驗(yàn)，增大緩存放大比，同時(shí)又要避免客戶報(bào)障，在做cache時(shí)可謂是煞費(fèi)苦心，大文件、小文件分離，在小文件里又把動態(tài)內(nèi)容和靜態(tài)內(nèi)容分離，能存的東西基本上全部存了，唯有動態(tài)內(nèi)容一直沒下手，按照之前的策略，動態(tài)內(nèi)容直接代理，1:1的進(jìn)出，可是某些局方就是不消停，非要達(dá)到某個(gè)放大比，沒折了，在動態(tài)內(nèi)容里面動一下刀吧。

    在動刀之前，先做分析，對能存的動態(tài)內(nèi)容和ATS的緩存策略做了大量測試，受益匪淺。當(dāng)前ATS的緩存策略完全按照http協(xié)議規(guī)定，采用最保守的緩存方式，即只對有明確生命周期緩存頭的信息進(jìn)行存儲，動態(tài)、cookie、authorization、no-cache一律不存，ats中對應(yīng)的配置參數(shù)就不寫了。為了保證質(zhì)量，直接把帶cookie、和授權(quán)的動態(tài)內(nèi)容略過了，原因就是風(fēng)險(xiǎn)太大，剩余的有這幾類可以嘗試：

1、有明確生命周期頭的動態(tài)url圖片等內(nèi)容；（我們假設(shè)網(wǎng)站的頭信息是可信的）

2、沒有明確頭生命周期頭的靜態(tài)url圖片、動態(tài)url圖片等，包括沒有任何信息的或只有l(wèi)ast-modified頭的圖片等信息。

對于第1類，很好處理，ats有相應(yīng)的參數(shù)，打開即可：

proxy.config.http.cache.cache_urls_that_look_dynamic INT 1

對于第2類，處理起來，就是個(gè)技術(shù)活了，首先線上對于頭信息的必要條件是：

proxy.config.http.cache.required_headersINT  2     

只有放開對這個(gè)的限制，才能把第2類給納括進(jìn)來，所以把其設(shè)置為0是第一必要，設(shè)置好后怎么保證其正常服務(wù)呢，比如說驗(yàn)證碼，他在設(shè)置的時(shí)候就是沒有頭信息，保守的策略肯定是正常服務(wù)，但這么一放開肯定報(bào)障。經(jīng)分析，ats對于沒有頭信息內(nèi)容的緩存時(shí)間走的是最大最小緩存時(shí)間來確保的，兩條時(shí)間參數(shù)如下:

proxy.config.http.cache.heuristic_min_lifetime INT 3600

proxy.config.http.cache.heuristic_max_lifetime INT 864000

對于只有l(wèi)ast-modified頭的信息是通過老化因子計(jì)算出來的，老化因子參數(shù)如下：

proxy.config.http.cache.heuristic_lm_factor-v 0.1

于是想出主意，內(nèi)容來后通存，但每次吐之前讓ATS發(fā)一個(gè)IMS頭信息給源站詢問是否有變化，由于這個(gè)頭信息只是詢問，不會占用多少流量，如果沒有變化就TCP_REFRESH_HIT吐給用戶，雖然回源了，但是內(nèi)容還是從緩存中吐出去的，如果有變化那就TCP_REFRESH_MISS吐給用戶，用戶拿到的同樣是最新內(nèi)容，這樣無形中會增加一部分吐流。

可是參數(shù)怎么設(shè)置呢？突然想到我可以把上面的參數(shù)都設(shè)置為0，理論上就達(dá)到了我的目的，第一次存下來，從第二次開始就IMS頭回源詢問，馬上找測試環(huán)境測試，果然跟料想的一樣，興奮之余立馬把策略更新到線上，通過流量圖工具監(jiān)控了一小時(shí)，回源總體是有所減少了，不過也發(fā)生了奇怪的事兒，用tsar看某些時(shí)刻的回源還是和吐的差不多，而且用traffic_logstats -s分析后發(fā)現(xiàn)有很多的ERR_CLIENT_ABORT,真是要命，這個(gè)日志是客戶端連接后數(shù)據(jù)還沒接收完就主動斷開了連接，少是正常的，多的話就有問題了，我找了個(gè)1M帶有max-age的圖片做測試，先purge一下，然后curl連接一下馬上斷開，制造這個(gè)錯(cuò)誤日志，第二次訪問，竟然是TCP_HIT,下載到本地圖片正常打開，要命啊，原來ATS在處理這種問題時(shí)會繼續(xù)下載到cache里面去，因?yàn)檫@批域名質(zhì)量本就差，所以造成回源流量時(shí)而還是很高，繼續(xù)想辦法google上找資料，找到了這條參數(shù)：

proxy.config.http.background_fill_completed_thresholdFLOAT 0.5

默認(rèn)是設(shè)置為0的，這個(gè)參數(shù)的意思是客戶端突然斷開，下載到百分之多少時(shí)會繼續(xù)下載，否則就會斷開，沒有多加考慮，設(shè)置為0.5，做了測試，然后馬上更新上去，流量穩(wěn)定了，吞吐量也上升了。

終于算是一個(gè)小圓滿，并不是線上的參數(shù)就這么穩(wěn)定了，后續(xù)根據(jù)業(yè)務(wù)情況還是需要調(diào)整測試的的，不過這也是樂趣所在吧。

所有的調(diào)整是一個(gè)平衡，當(dāng)前的調(diào)整：1、增加了磁盤讀寫IO；2、增加了cpu的負(fù)載。

以上就是ATS如何進(jìn)行緩存策略增加動態(tài)服務(wù)吞吐量的全部內(nèi)容了，更多與ATS如何進(jìn)行緩存策略增加動態(tài)服務(wù)吞吐量相關(guān)的內(nèi)容可以搜索億速云之前的文章或者瀏覽下面的文章進(jìn)行學(xué)習(xí)哈！相信小編會給大家增添更多知識,希望大家能夠支持一下億速云！