第3章 — 進階快取主題
「電腦科學中只有兩個硬性專案：快取失效和命名專案。」
— 菲爾·卡爾頓
概觀
這是AEM快取的三部分之系列的第3部分。 前兩個部分的重點在於Dispatcher中的普通http快取，以及限制有哪些。 本節探討如何克服這些限制的一些想法。
一般快取
此系列的第1章和第第2章主要著重於Dispatcher。 我們已說明基本知識、限制以及您需要進行某些取捨的位置。
快取複雜性和複雜性並非Dispatcher特有的問題。 一般而言，快取相當困難。
將Dispatcher作為工具箱中唯一工具實際上是一種限制。
在本章中，我們想要進一步擴大快取檢視的範圍，並提出一些如何克服Dispatcher某些缺點的想法。 沒有靈丹妙藥 — 您必須在專案中進行權衡。 請記住，快取和失效準確性永遠伴隨著複雜性，複雜性也伴隨著錯誤的可能性。
您需要在這些領域進行取捨，
- 效能和延遲
- 資源消耗/CPU負載/磁碟使用量
- 準確性/貨幣/過時/安全性
- 簡易性/複雜性/成本/可維護性/錯誤傾向
這些維度在一個相當複雜的系統中相互連結。 沒有簡單的if-this-then-that。 讓系統更簡單可讓速度更快或更慢。 它可以降低您的開發成本，但會增加服務檯的成本，例如，如果客戶看到過時內容或抱怨網站速度緩慢，就會增加成本。 所有這些因素都需要相互考量和平衡。 但現在您應該已經有了好主意，沒有萬靈丹妙藥，也沒有單一的「最佳實務」 — 只有許多不良實務，以及少數好實務。
鏈結快取
概觀
資料流程
從伺服器傳送頁面至使用者端的瀏覽器，可跨越許多系統和子系統。 若您仔細檢視，有許多躍點資料需要從來源移至漏出，每個躍點資料都可能是快取的候選專案。
典型CMS應用程式的資料流程
讓我們從硬碟上需要顯示在瀏覽器中的資料片段開始歷程。
硬體與作業系統
首先，硬碟機(HDD)本身在硬體中有一些內建快取記憶體。 第二，裝載硬碟的作業系統使用可用的記憶體來快取經常存取的區塊，以加快存取速度。
內容儲存庫
下一個層級是CRX或Oak - AEM使用的檔案資料庫。 CRX和Oak將資料分割成可快取到記憶體中的區段，以避免存取硬碟的速度變慢。
第三方資料
大多數大型的Web安裝也有第三方資料；資料來自產品資訊系統、客戶關係管理系統、舊版資料庫或任何其他任意Web服務。 我們不需要在需要這些資料時隨時從來源提取這些資料，尤其是在我們已知這些資料的變更頻率不太高時。 因此，如果它未在CRX資料庫中同步，則可快取。
業務層 — 應用程式/模型
通常您的範本指令碼不會透過JCR API轉譯來自CRX的原始內容。 最有可能的情況是，您之間有業務層，可合併、計算及/或轉換業務領域物件中的資料。 猜猜看，如果這些操作很昂貴，您應該考慮快取它們。
標籤片段
模型現在是呈現元件標示的基礎。 為什麼不同時快取演算後的模型？
Dispatcher、CDN和其他代理人
關閉會將轉譯的HTML頁面前往Dispatcher。 我們已討論，Dispatcher的主要用途是快取HTML頁面和其他網路資源（儘管其名稱）。 在資源到達瀏覽器之前，它可能會傳遞反向Proxy （可以快取）和CDN （也用於快取）。 使用者端可能位於辦公室中，僅透過Proxy授與Web存取權，該Proxy也可能決定快取並儲存流量。
瀏覽器快取
最後但並非最不重要的一點是，瀏覽器也會快取。 這是一項容易被忽略的資產。 但這是您在快取鏈結中最接近且最快的快取。 很遺憾，使用者之間不共用，但一位使用者的不同請求之間仍會共用。
快取的位置及原因
這是一長串潛在快取記憶體。 我們都遇到過問題，看到過時的內容。 但是考慮到這個階段有很多，它大部分時間都運作起來是個奇蹟。
但快取在鏈條的哪個角落有意義？ 在開頭？ 在結尾？ 到處都是？ 這取決於……而且取決於許多因素。 即使是相同網站中的兩個資源，也可能希望以不同的方式回答此問題。
讓您大致瞭解可能考量的因素，
存留時間 — 如果物件的固有存留時間較短（流量資料的存留時間可能比天氣資料短），則可能不值得快取。
生產成本 — 物件的重新生產與傳遞是多麼昂貴（就CPU週期和I/O而言）。 如果是便宜的快取，可能就不需要了。
大小 — 大型物件需要快取更多資源。 這可能是限制因素，必須與其收益相平衡。
存取頻率 — 如果物件很少被存取，則快取可能無效。 在第二次從快取存取之前，它們只會過時或失效。 這類專案只會封鎖記憶體資源。
共用存取 — 一個以上實體使用的資料應該快取到鏈結的上方。 實際上，快取鏈不是鏈，而是樹。 一個以上模型可能會使用存放庫中的一個資料。 這些模型接著便可由多個轉譯器指令碼用來產生HTML片段。 這些片段包含在多個頁面中，這些頁面透過瀏覽器的私人快取分配給多個使用者。 因此，「共用」並不表示只在不同人之間共用，而是在不同軟體之間共用。 如果您想要尋找潛在的「共用」快取，只要將樹追溯到根並尋找共同祖項 — 也就是您應該快取的位置。
地理空間分佈 — 如果您的使用者分散在世界各地，使用分散式快取網路可能有助於減少延遲。
網路頻寬和延遲 — 說到延遲，您的客戶是誰，他們使用哪種網路？ 或許您的客戶是使用3G連線的舊版智慧型手機的缺發達國家行動客戶？ 請考慮建立較小的物件，並在瀏覽器快取中快取它們。
這份清單目前尚不完整，但我們認為您現在已經有了想法。
鏈結快取的基本規則
再說一次 — 快取是硬的。 讓我們分享我們從先前專案擷取的一些基本規則，這些規則可協助您避免專案中的問題。
避免雙重快取
上一章介紹的每個層都會提供快取鏈結中的某些值。 藉由節省運算週期或讓資料更貼近消費者。 在鏈結的多個階段快取資料片段並沒有錯，但您應該一律考慮下一個階段的好處與成本。 在Publish系統中快取完整頁面通常沒有任何好處，因為這項操作在Dispatcher中已經完成。
混合失效策略
有三種基本失效策略：
- TTL，存留時間： 物件會在固定時間後到期（例如「從現在起的2小時」）
- 到期日： 物件會在未來的指定時間到期（例如「2019年6月10日下午5:00」）
- 以事件為基礎： 物件因平台中發生的事件而明確失效（例如，當頁面變更並啟動時）
現在您可以對不同快取層使用不同策略，但有一些「有毒」策略。
事件型失效
純事件型失效：從內部快取到外層失效
純事件型失效是最容易理解、在理論上最容易正確且最準確的失效方式。
簡而言之，物件變更後，快取會逐一失效。
您只需要記住一個規則：
永遠從內部到外部快取失效。 如果您先讓外部快取失效，它可能會從內部快取重新快取過時的內容。 不要在快取重新整理的時間做任何假設 — 請確定。 最好在 使內部快取失效之後，觸發外部快取失效。
這就是理論。 但實際上有許多疑問。 事件必須分發 — 可能透過網路分發。 在實務中，這會使其成為最難實施的失效方案。
自動 — 修復
若使用事件型失效，您應該有應急計畫。 如果遺漏失效事件，該怎麼辦？ 簡單的策略可能是在一段時間後讓無效或清除。 因此，您可能已錯過該活動，現在提供過時的內容。 但您的物件也只有數小時（天）的隱含TTL。 所以最終系統會自動自我修復。
純TTL型失效
未同步的TTL型失效
這個也是相當常見的配置。 您可以棧疊數個快取圖層，每個圖層都有權在特定時間內提供物件。
實作容易。 不幸的是，很難預測資料片段的有效壽命。
外部快取會延長內部物件的壽命
請考量上圖。 每個快取層都會引入2分鐘的TTL。 現在 — 整體TTL也必須2分鐘，對嗎？ 不盡然。 如果外層在物件過期之前擷取物件，則外層實際上會延長物件的有效存留時間。 在這種情況下，有效上線時間可介於2到4分鐘之間。 假設您同意業務部門的意見，一天是可以容忍的 — 而且您有四個快取階層。 每個圖層上的實際TTL不可超過六小時……增加快取遺漏率……
我們並不是說這是個糟糕的配置。 您應該知道它的限制。 而且這是一個簡單好用的開始策略。 只有在網站的流量增加時，您才會考慮更精確的策略。
設定特定日期，以同步處理失效時間
以到期日為基準的失效
如果您在內部物件上設定特定日期，並將此日期傳播至外部快取，即可獲得更可預測的有效期限。
正在同步處理到期日期
不過，並非所有快取都能傳播日期。 而且，當外部快取彙總了兩個具有不同到期日的內部物件時，可能會變得非常糟糕。
混合事件型和TTL型失效
混合事件型與TTL型策略
此外，AEM世界中的常見配置是在內部快取（例如記憶體中的快取，其事件可以近乎即時地處理）中使用事件型失效，而在外部則使用TTL型快取，因此您可能沒有明確失效的存取權。
在AEM世界中，當基礎資源變更時，您在Publish系統中將有用於商業物件和HTML片段的記憶體內快取，並且您將此變更事件傳播到也可使用基於事件的排程程式，這會失效。 例如，您之前會有TTL型CDN。
在Dispatcher前面有一層（短）TTL型快取，能夠有效地軟化自動失效後通常會出現的尖峰。
混合TTL — 和事件型失效
有毒：混合TTL — 和事件型失效
這種組合是有毒的。 切勿在TTL或到期型快取之後放置和事件型快取。 還記得我們在「純TTL」策略中所具有的溢位效應嗎？ 在這裡可以觀察到相同的效果。 只有已發生的外部快取失效事件才不會再次發生。如此一來，您快取物件的生命週期就會無限延長。
TTL型和事件型合併：溢位至無限
部分快取和記憶體內部快取
您可以掛接至演算程式的階段，以新增快取圖層。 從取得遠端資料傳輸物件或建立本機企業物件，到快取單一元件的演算標籤。 我們將在稍後的教學課程中討論具體實施。 但或許您打算自己已經實作這些快取階層中的幾個。 因此，我們在這裡至少可以介紹基本原則，以及格鬥原則。
