將追加的主題

• 內存常駐副本(resident alternates)
• 緩存對象刷新(object refresh)

緩存一致性(Cache Consistency)

ATS緩存是完全一致性的，除非你不小心踢掉電源，讓ATS突然關機。如果要禁用硬盤驅動器自身的緩存，你需要使用下面的命令

hdparm -W0

緩存系統會校驗可用文檔(document)的所有數據，并默認將不完整的文檔標記為讀MISS。無須小心翼翼地關閉ATS，你只需簡單殺死ATS進程，下次ATS啟動后，緩存恢復代碼fsck會每隔一定時間運行。

ATS啟動后，會檢查兩種目錄版本(注意cache帶中會有首尾兩個VolHeaderFooter結構)，最后會將合法的目錄讀入內存中。ATS會從上次突然中斷的寫光標處開始向前移動，讀取所有寫到磁盤中的分片(fragment)，并更新目錄(就像基于日志的文件系統)。在寫操作的時候，讀操作會停下來，直至看到上次合法的寫頭部(last valid write header)，因為磁盤扇區的重新排序，寫操作不一定是原子的。那些新更新的操作會寫到非法的(invalid)版本里(萬一系統啟動過程中崩潰了呢)，然后系統啟動了。

緩存分卷標簽(Volume Tagging)

當前緩存分卷在緩存設備上的分配有些隨意，一個增強版本1允許storage.config分配特定的緩存帶給特定的緩存分卷，但是通常volume.config中仍然需要配置這些緩存分卷，特別是要映射那些域名到指定的緩存分卷。這樣做的一個主要用途就是映射指定類型的內容到不同的緩存設備(SSD或是普通機械硬盤)上。比如在storage.config中配置：

/dev/sda object_size=8k volume=1
/dev/sdb object_size=1M volume=2

ATS版本升級

當前對緩存格式的任何變動都會導致ATS清除緩存。當升級ATS版本時，一定要記住這一點。

緩存Key控制

緩存key默認是請求的URL。有兩種可能的選擇，原始URL和重映射(remapped)后的URL，使用哪個URL，由下面的配置項決定：
proxy.config.url_remap.pristine_host_hdr
這是INT值，假如設置為0(禁用)，使用remapped的URL，假如設置為非0值(啟用)，使用原始URL。這個配置項也會影響發送給源站的請求中的Host頭的值，假如是0，使用重定向后URL中的hostname，否則使用原始URL中的hostname，此外沒有其它影響。

對于緩存來說，如果沒有使用到重定向規則，或者原始URL和重定向URL僅是一一對應的映射關系，對緩存來說，基本上沒有啥影響。

假如多個原始URL映射到同一個重定向URL，情況就有些復雜。假如啟用了本真頭(pristine header)，對不同原始URL的請求將會存儲為不同的對象，假如禁用，就只會使用重定向后的URL存儲，這會造成沖突(collision)。假如這些內容不相同，這就很糟糕，但是假如它們的內容都相同(類似原始URL僅是僅是同一源站資源的別名這種情況)，這就比較有用了。

假如原有重映射規則改變了，就會有問題。假如原始URL重映射到一個不同的服務器地址，上面的配置項將會決定是已經緩存的對象響應新的客戶端請求(啟用時)，還是不響應(不啟用)。類似地，假如重映射規則中的原始URL改變了，那么假如禁用本真頭，來自最初原始URL的緩存對象將會響應客戶端請求，而不是更新后的原始URL對應的緩存對象來響應客戶端請求。

這些沖突自身來說沒有好壞之分，管理員需要根據自己的業務場景來確定合適的值并做相應的設置。

假如需要更大程度地控制，可以在插件中調用API函數TSHttpTxnCacheLookupUrlSet()或TSCacheUrlSet() 來設置專門的緩存key。TSCacheUrlSet()接口能最早在TS_HTTP_READ_REQUEST_HDR_HOOK鉤子中調用，但最晚必須在TS_HTTP_POST_REMAP_HOOK鉤子中調用。每個事物(transaction)中只能調用一次。多次調用該API沒有任何作用。

改變緩存key的插件必須對緩存HIT和緩存MISS這兩種情況做出一致性處理。因為對映射到同一個緩存key的不同請求，緩存應該做同樣的處理。直接使用URL是這樣做的，任何其它的替代品也應該是這樣。這完全是插件的責任，對ATS內核來說，沒有辦法知道這些細節。

當使用TSHttpTxnCacheLookupUrlSet()或TSCacheUrlSet() 設置了新的緩存url之后，可以調用TSHttpTxnCacheLookupUrlGet()函數來查看新設置的緩存url，應該使用TSUrlCreate()生成的URL定位符(URL location)來作為第三個參數，而不是從客戶端請求中獲取url_loc.

一般要求緩存url是形如URL的字符串，但是也可以完全隨意，并且不一定要求含有path。比如，假如Network Geographic公司想使用它自己的緩存key來存儲每個資源，使用文檔GUID作為key的一部分，緩存key類似

ngeo://W39WaGTPnvg

格式ngeo專門拿出來說，是因為它不是一個合法的URL格式(scheme)，因而也不會與任何合法的URL沖突。

假如將重要和不重要的數據都編碼進URL，可能很有用，事實上，可創建和使用只含有重要數據部分的url來存放數據，而不必使用多個不同的URL(僅在不重要的數據部分有區別)來存放潛在相同的內容。

比如假設Network Geographic公司的內容URL使用文檔GUID和Refferrer頭鍵(referral key)組合來編碼：

http://network-geographics-farm-1.com/doc/W39WaGTPnvg.2511635.UQB_zCc8B8H

這里Referrer頭的值為http://network-geographics-farm-1.com/doc，GUID為W39WaGTPnvg.2511635.UQB_zCc8B8H。我們對每個可能的Referrer不想提供相同的內容(還要考慮后面的GUID呀)，而是，我們想使用一個插件來將這種情況轉換為前面的例子(只有GUID)，僅是Referrer key不同的請求(后面GUID必須一樣)將會引用相同的緩存對象。注意我們也映射下面的url到相同的緩存key

http://network-geographics-farm-56.com/doc/W39WaGTPnvg.2511635.UQB_zCc8B8H

當內容完全相同時，這將會很方便地讓不同的源站返回相同的內容，插件可以改變緩存key，或者不改變，這依賴請求頭中的相關數據。比如，假如請求的PATH不在doc目錄中，就不改變緩存key。假如需要區分服務器，可以輕易從請求URL獲取內容并用來組合緩存key。實現者可以很自由地從緩存key中提取出所有的相關元素。

當沒有明確要求時，組合緩存key基于HTTP請求頭，實際上，因為一致性要求它通常很有必要。因為緩存查找發生在回源連接之前，我們無法獲取到HTTP響應頭的任何信息，除了僅有的請求頭，最常用的情形是上面描述的，我們的目的就是剔除URL中不影響存儲內容的元素，來將緩存容量最小化，同時提高緩存命中率。

參考文檔

https://docs.trafficserver.apache.org/en/latest/developer-guide/architecture/consistency.en.html

總結

以上是生活随笔為你收集整理的ATS缓存相关话题的全部內容，希望文章能夠幫你解決所遇到的問題。

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