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型和事件型合併:溢位至無限
部分快取和記憶體內部快取
您可以掛接至演算程式的階段,以新增快取圖層。 從取得遠端資料傳輸物件或建立本機企業物件,到快取單一元件的演算標籤。 我們將在稍後的教學課程中討論具體實施。 但或許您打算自己已經實作這些快取階層中的幾個。 因此,我們在這裡至少可以介紹基本原則,以及格鬥原則。