下面是參考文獻[1]的翻譯


簡介
ATS既可以用作HTTP代理，也可以用作HTTP緩存，ATS能夠緩存任何字節流，雖然它當前只支持HTTP協議傳輸的字節流，當這樣的流緩存時，會帶一個HTTP協議頭部，會命名為緩存中的一個對象object。每個對象通過一個名為cache key的全局唯一值識別。
該文檔的目的是描述ATS緩存的基本結構和實現細節。緩存的配置只討論到需要理解內部機制的程度。這篇文檔對ATS源碼和插件(codebase or plugins)開發者很有幫助。該文檔假定讀者對管理員文檔已經比較熟悉，特別是對其中的HTTP Proxy Caching[2]和Configuring the Cache[3]以及相關的配置和值比較熟悉。
很遺憾內部術語并不特別一致，所以該文檔將會頻繁使用不同方式的術語，以達到某種一致性。


緩存結構Cache Layout
下面的小節描述了持久緩存數據persistent cache data的組織細節。ATS將它的持久存儲視作一個毫不加區分的字節的集合，假設再沒有其它結構描述它。特別地，它并不會用到操作系統的文件系統。
假如使用一個file，僅是表明要用到它所含的字節集合。


Cache storage

ATS緩存的原生storage在storage.config中配置，文件中的每行描述了一個cache span，它被視作一個統一的持久存儲。

該storage進一步被組織成一個cache volumes的集合，在volume.config文件中配置，它被用作其它管理級別配置的單位。
cache volumes可以定義為total storage的百分比，或者storage的絕對量。為了穩妥，默認每個cache voluem分散到所有的cache span。
cache volume和cache span的交集是cache stripe。每個cache span分割為cache stripes，每個cache volumes可以定義為total是這些stripes的集合。
假如這個cache spans例子中的cache volumes定義如下

那么實際的結構layout形如

cache stripes是該實現的緩存基礎單元，一個cached object完整存放在單個stripe中，因而也在單個cache span中。緩存對象絕不會分割后存放到多個span紅色volumes中。
Objects被指定到一個stripe，因而被指定到一個cache volume，自動基于URI的hash去檢索來自源站的object。可以在hosting.config中做配置來限制對象的廣度。
該配置文件支持將指定的hosts和域名存放到特定的cache volumes。從4.0.1版本后，也可以控制哪些cache spans，因而哪些cache stripes包含在指定的cache volumes中。


cache spans，cache volumes和cache stripes(組成前兩者)的結構(layout and structure)完全來自storage.config和cache.config的配置，當traffic_server啟動時

會從頭重新計算。因此，那些配置文件的任何變化都能(差不多總是)導致現存緩存的完整性失效。

Stripe Structure
ATS將與cache stripe相關的storage視作一個不加區分的字節帶(span of bytes).在內部，每個stripe視作毫不相關。本節描述的數據結構僅針對stripe內部。
在源碼中術語volume用作cache stripe，主要在Vol中實現，讀者稱作volume的東西(本文檔稱作cache volume)，這里表示為CacheVol。


注意
stripe劃分必須在處理object之前，因為object所在的目錄在stripe內部，當stripe劃分改變時，其中所含的任何緩存對象cached objects必定會丟失，因為它們的目錄數據不會在新stripe中找到。


緩存目錄Cache Directory
stripe中的內容通過目錄directory追蹤，目錄中的每個元素就是directory entry，表示為Dir。每個元素引用緩存中的一段連續存儲區，它們有各種稱呼，比如fragments，segments，docs，documents，和其它說法。總體來說，目錄就是以cache ID為key的一個hash。參見directory probing去了解如何使用cache ID來定位一個directory entry。cache key是content的URL，cache ID由cache key計算得到。


directory用作內存中的駐留結構memory resident structure，這意味著directory entry要盡可能小，當前為10個字節。這迫使存放的數據做某些妥協。另一方面，這意味著，絕大多數cache miss不要求磁盤I/O，這樣將會有相當大的性能優勢。


目錄總是完全劃分好的，一旦stripe初始化好，對應的directory大小就是固定的，絕不會再改變，并與stripe大小（近似線性）相關。這就是ATS內存footprint與磁盤緩存大小緊密相關的原因。因為目錄大小不變，對內存要求也不變，所以ATS隨著緩存中存放內容的增多并不會再消耗更多的內存。假如當緩存為空時，運行ATS足夠，那么當緩存存滿后，運行ATS也是足夠的。


每個directory entry中存放了在stripe中的offset和size，size是fragment中實際數據大小的近似值(至少大于)，精確的size data存放在磁盤中fragment header中。
注意

HTTP headers中的數據不經過磁盤I/O并不能檢查。這包括對象的original URL， cache key沒有精確存放，因而不能可靠地檢索到。

……

緩存初始化Initialization
緩存初始化會開啟一個Store實例，通過讀storage配置文件，默認為storage.config。對該配置文件中的每個合法元素，會創建一個Span實例，基本上有四種類型的實例：File，Directory，Disk，Raw device。
在生成所有的Span實例后，它們按device ID分組到內部鏈表中并掛接到Store::disk數組上。引用同一個目錄，磁盤或裸盤的那些Spans被組合進同一個span中。引用同一個文檔但是偏移重疊的Spans也被組合起來，這些工作都在ATS啟動時調用ink_cache_init()完成。
span logic也被HostDB使用到，不止一個莫名其妙的feature在那個模塊中出現。
在配置初始化后，cache processor調用CacheProcessor::start()，它做了許多事情：
對每個合法的span，創建一個CacheDisk實例，CacheDisk類是一個continuation，能在span上用來執行阻塞操作，該類的主要作用就是傳遞到AIO線程作為I/O操作完成時的回調函數，然后會傳遞到AIO薪酬執行storage unit的初始化，在所有這些工作完成后，在cplist_reconfigure()中，得到的storage會分發到volumes中，那時再生成CacheVol實例。

(未完待續……)

單詞表
parcel out ?分配，把…分成幾份
coalesce ?使…聯合，使…合并
inexplicable ?費解的，莫名其妙的

rationale ? 基本原理
ballpark ?大致的，大約的
millage ?稅率

wholly unjustified ?完全不合理

false negative 誤報

參考文獻
[1].https://docs.trafficserver.apache.org/en/latest/developer-guide/architecture/architecture.en.html
[2].https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#http-proxy-caching

[3].https://docs.trafficserver.apache.org/en/latest/admin/configuring-cache.en.html#configuring-the-cache

[4].https://github.com/portl4t/trafficserver-doc-zh/blob/master/arch/cache/cache-arch.md

總結

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

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