事先說明

標題說是“坑”，并沒有說是“bug”，也就是多半是玩的姿勢不對。

線上問題

我司(lecloud)目前線上大小文件都是使用的ATS 6.2.1版本，昨天運維反饋有文件超過緩存時間并不回源刷新，截圖如下：

現象就是：age超過max-age了，過期了不更新！

另外需要說的一點就是，源站是可以正常回源的。

復現現象并打印調試日志

我復現了上述現象，發現問題的確如此，而且重啟ATS之后，問題依舊。

這個問題，最本源的解決途徑，就是去分析ATS對該請求的具體執行過程，特別是在判斷緩存對象的refreshness這一塊兒的判斷細節。按照這個思路，我打開records.config中的debug選項，只過濾http.*相關的日志，traffic_line -x讓配置生效后, 重新觸發請求，得到了該請求完全的處理日志，我已經上傳，參見下面的鏈接

https://download.csdn.net/download/tao_627/10845892

仔細分析該日志，與我最初的想法有些差異。我最初以為，這種情況下ATS回去回源校驗，發現源站的內容沒有變化，得到源站的304響應，然后還是將緩存中的內容返回給客戶端，此時Age值繼續增大。但是我仔細分析http請求的處理日志，發現并不是這樣，ATS直接查緩存，并且校驗緩存中的內容是refresh之后，就直接讀取緩存并返回響應給客戶端了。

那么這里值得懷疑的地方，就只能鎖定在ATS對緩存object的refreshness的處理是否存在問題。

代碼定位

從日志中的行號指示，主要定位到如下幾個函數

注意這里

日志和代碼一一對應上

可以看出，這里對緩存中一個document的freshness_limit的判斷非常重要，優先考慮的是Cache-Control: s-maxage, 然后是max-age，如果沒有這兩個頭，就再考慮Expires頭，然后是Last-Modified/Date頭，使用Last-Modified和Date頭計算freshness_limit時，會用到下面的加權因子proxy.config.http.cache.heuristic_lm_factor，默認是0.10

freshness_limit = (date - last_modified) * 0.10

如果上面的http頭都沒有，直接使用配置值中的最小經驗值proxy.config.http.cache.heuristic_min_lifetime

freshness_limit = s->txn_conf->cache_heuristic_min_lifetime

s-maxage與max-age的唯一區別是,s-maxage僅僅應用于共享緩存，而不應用于用戶代理的本地緩存等針對單用戶的緩存。另外,s-maxage的優先級要高于max-age.

上面的計算過程中，都使用到配置項proxy.config.http.cache.guaranteed_max_lifetime和proxy.config.http.cache.guaranteed_min_lifetime來限定一個緩存object的freshness_limit必須在這兩者之間，默認配置情況下，也就是必須在一年以內。

CONFIG proxy.config.http.cache.guaranteed_max_lifetime INT 31536000

?

原因定位

ATS的官網文檔

https://docs.trafficserver.apache.org/en/6.2.x/admin-guide/files/records.config.en.html

中有這個配置選項

proxy.config.http.cache.guaranteed_max_lifetime

默認配置是一年，在一年內會按照過期策略進行回源。? 如果超過了， 在目前的配置下(恰好我們也是配置的1年)直接響應。在當前情況下，就會導致該資源永不過期。

解決方法

更新records.config文件，在末尾增加一行，將對象緩存時間最大設置為10年，或其它合適的值
CONFIG proxy.config.http.cache.guaranteed_max_lifetime INT 315360000
然后更新配置文件(不需要重啟ats)
/usr/local/ats/bin/traffic_line -x

可見，還是我們對ATS 6.2.1的新特性不熟，導致掉進“坑”里了，屬于玩的姿勢不對。

?

總結

以上是生活随笔為你收集整理的ATS 6.2.1中缓存文件过期并不回源校验的“坑”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。