Show Menu
主題×

Dispatcher 綜覽

Dispatcher 版本與 AEM 無關。如果您依循連結至 Dispatcher 文件,且該連結內嵌於舊版 AEM 的文件中,您可能會被重新導向至本頁。
Dispatcher 是 Adobe Experience manager 的快取和/或負載平衡工具。使用 AEM 的 Dispatcher 也有助於保護您的 AEM 伺服器不受攻擊。因此,您可以搭配使用 Dispatcher 與企業級 Web 伺服器,以提高 AEM 例項的安全性。
部署 Dispatcher 的程序與所選的 Web 伺服器和作業系統平台無關:
  1. 瞭解 Dispatcher (本頁)。此外,請參閱 調度程式的相關常見問題
  2. 根據 Web 伺服器文件安裝 支援的 Web 伺服器
  3. 在 Web 伺服器上安裝 Dispatcher 模組 ,並相應地設定 Web 伺服器。
  4. 設定 Dispatcher (dispatcher.any 檔案)。
  5. 設定 AEM ,如此一來內容更新即可讓快取失效。
若要進一步瞭解 Dispatcher 如何與 AEM 搭配運作,請參閱 2017 年 7 月的「詢問 AEM 社群專家」
視需要使用下列資訊:
Dispatcher 最常見的用法是快取來自 AEM
Publish 例項的回應​****,以提高您對外發佈網站的回應速度與安全性。大多數的討論均強調此用途。
但是,Dispatcher 也可用來提高您​
Author 例項
​的回應速度,尤其是如果您有大量使用者編輯和更新您的網站時特別實用。如需針對此情況的詳細資料,請參閱下方的「搭配使用 Dispatcher 與 Author 伺服器」。 將 Dispatcher 與 Author 伺服器搭配使用

為何要使用 Dispatcher 實作快取?

網路出版的基本方式有兩種:
  • 靜態 Web 伺服器
    : 例如 Apache 或 IIS,都非常簡便而快速。
  • 內部管理伺服器
    : 提供動態且即時的智慧型內容,但是需要較多的運算時間和其他資源。
Dispatcher 有助於實現快速和動態的環境。這可當成是靜態 HTML 伺服器 (例如 Apache) 的一部分,但其目的是:
  • 以靜態網站的形式,盡可能儲存 (或「快取」) 網站內容
  • 儘可能減少存取版面引擎。
這表示:
  • 處理靜態內容
    ​的速度和簡便性與在靜態 Web 伺服器上完全相同;
    此外,您可以使用可用於靜態 Web 伺服器的管理和安全工具
  • 動態內容
    ​會視需要產生,除非絕對需要,否則並不會讓系統變慢。
Dispatcher 包含的機制可根據動態網站上的內容來產生和更新靜態的 HTML。您可以詳細指定要將哪些文件儲存為靜態檔案,哪些一律動態產生。
本節說明這背後的原理。

靜態 Web 伺服器

靜態 Web 伺服器 (例如 Apache 或 IIS) 會為網站的訪客提供靜態 HTML 檔案。靜態頁面只需建立一次,之後會針對每項請求傳送相同的內容。
此過程非常簡單,因此非常有效率。如果訪客要求檔案 (例如 HTML 頁面),則通常會直接從記憶體擷取檔案,不然頂多是從本機磁碟讀取檔案。靜態 Web 伺服器已上市相當長一段時間,因此已經有多種管理和安全管理工具,並且與網路基礎架構高度整合。

內容管理伺服器

如果您使用的是內容管理伺服器 (例如 AEM),進階版面引擎會處理訪客的請求。引擎會從存放庫讀取內容,並結合樣式、格式和存取權限,將內容轉換為符合訪客需求和權限的文件。
這可讓您建立更豐富的動態內容,進而提高網站的彈性和功能。不過,版面引擎比靜態伺服器需要更強大的處理能力,因此,如果有許多訪客使用系統,此設定可能會讓速度緩慢。

Dispatcher 如何執行快取

快取目錄
​針對快取,Dispatcher 模組會使用 Web 伺服器的功能提供靜態內容。Dispatcher 會將快取的文件置於 Web 伺服器的文件根目錄中。
當缺少 HTTP 標頭快取的設定時,Dispatcher 只會儲存頁面的 HTML 程式碼,不會儲存 HTTP 標 題。如果您的網站使用不同的編碼,可能會發生問題,因為這些編碼可能會遺失。如要啟用 HTTP 標頭快取,請參閱 設定 Dispatcher 快取。
在網路連接儲存裝置 (NAS) 上尋找 Web 伺服器的文件根目錄會導致效能降低。此外,當位於 NAS 上的文件根目錄在多個 Web 伺服器之間共用時,執行複製操作時可能會發生間歇鎖定。
Dispatcher 將快取的文件以與請求的 URL 相同的結構儲存。
檔案名稱的長度可能受到作業系統層級的限制,若您有包含多個選取器的 URL 就會如此。

快取方法

Dispatcher 有兩種主要方法,用於在對網站進行更改時更新快取內容。
  • 內容更新
    ​會移除已變更的頁面,以及與其直接相關的檔案。
  • 自動失效
    ​功能會自動讓那些在更新後可能過期的快取失效。即此功能會有效率地將相關頁面標示為過期,而不會刪除任何內容。

內容更新

每次內容更新會變更一或多個 AEM 文件。AEM 會傳送整合請求給 Dispatcher,Dispatcher 會隨之更新快取:
  1. 它會從快取中刪除修改過的檔案。
  2. 它會從快取中刪除以相同名稱開頭的所有檔案。例如如果 file /en/index.html 已更新,則所有以 /en/index 開頭的檔案都會遭到刪除。此機制可讓您設計快取效率高的網站,尤其是在圖片導覽方面。
  3. 它​
    會接觸到
    ​所謂的
    statfile
    ;進而更新 statfile 的時間戳記,以顯示上次變更的日期。
請注意下列幾點:
  • 內容更新通常與編寫系統搭配使用,因而「知道」必須取代的內容。
  • 受內容更新影響的檔案會遭到移除,但不會立即替換。下次請求此類檔案時,Dispatcher 會從 AEM 例項擷取新檔案,並將其置於快取中,藉此來覆寫舊內容。
  • 通常,包含頁面文字的自動產生圖片,會儲存在開頭為相同名稱的圖片檔案中,因而可確保要刪除的檔案的關聯性存在。例如您可以將頁面 mypage.html 的標題文字儲存為相同檔案夾中名稱為 mypage.titlePicture.gif 的圖片。如此一來,每次更新頁面時,圖片都會自動從快取中刪除,因此您可以確定圖片會一律反映頁面的最新版本。
  • 您可能有數個 statfile,例如每個語言檔案夾一個。如果頁面已更新,AEM 會尋找下一個包含 statfile 的上層檔案夾,並​
    接觸
    ​該檔案。

自動失效

自動失效功能會自動讓部分的快取失效,而不會實際刪除任何檔案。在每次內容更新時,都會接觸到所謂的 statfile,因此其時間戳記都會顯示最後一次的內容更新。
Dispatcher 有一個檔案清單,這些檔案會自動失效。請求該清單中的文件時,Dispatcher 會將快取文件的日期與 statfile 的時間戳相比較:
  • 如果快取的文件較新,則 Dispatcher 會傳回快取的文件。
  • 如果快取的文件版本較舊,則 Dispatcher 會從 AEM 例項擷取最新版本。
同樣請您注意下列幾點:
  • 當內部關係複雜 (例如 HTML 頁面) 時,通常會使用自動失效。這些頁面包含連結和導覽項目,因此通常必須在內容更新後加以更新。如果您已自動產生 PDF 或圖片檔,也可以選擇自動使這些檔案無效。
  • 除了會接觸到 statfile,自動失效不涉及調度程式在更新時執行的任何操作。不過,觸及 statfile 會自動使快取內容逾時,而不會從快取中實際刪除檔案。

Dispatcher 如何傳回文件

確定文件是否會進入快取

您可以定義 Dispatcher 在設定檔案中快取的文件 。Dispatcher 會根據可快取文件清單來檢查請求。如果文件不在此清單中,Dispatcher 會請求 AEM 例項的文件。
在下列情況下,** Dispatcher 一律會直接從 AEM 例項要求文件:
  • 如果請求 URI 包含問號「?」。這通常表示這是一個不需要快取的動態頁面,例如搜尋結果。
  • 缺少檔案副檔名。Web 伺服器需要副檔名來判斷文件類型 (MIME 類型)。
  • 驗證標頭已設定 (這可以設定)
GET 或 HEAD (用於 HTTP 標頭) 方法可讓 Dispatcher 快取。如需回應標頭快取的詳細資訊,請參閱 快取 HTTP 回應標題 區段。

確定是否已快取文件

Dispatcher 會將快取的檔案儲存在 Web 伺服器上,就像是靜態網站的一部分一樣。如果使用者請求可快取文件,Dispatcher 會將檢查該文件是否存在於 Web 伺服器的檔案系統中:
  • 如果已快取該文件,則 Dispatcher 會將檔案傳回。
  • 如果未快取,則 Dispatcher 會從 AEM 例項要求該文件。

確定文件是否為最新版本

為了要瞭解文件是否為最新版本,Dispatcher 會執行下列兩個步驟:
  1. 它會檢查文件是否會自動失效。如果不會,則可將該文件視為最新版本。
  2. 如果文件已設定為會自動失效,Dispatcher 會檢查其是否比最後一次可用變更來得舊或更新。如果版本較舊,Dispatcher 會請求來自 AEM 例項的最新版本,並取代快取中的版本。
未​
自動失效
​的文件會保留在快取中,直到實際上遭到刪除 (例如透過網站上的內容更新) 為止。

負載平衡的優點

「負載平衡」是將網站的運算負載分配至數個 AEM 例項的作法。
其優點如下:
  • 提高處理能力
    ​在實務中,這表示 Dispatcher 會與數個 AEM 例項共用文件請求。由於每個例項現在要處理的文件數量較少,因此您的回應時間就會變快。Dispatcher 會保留每個文件類別的內部統計資料,以便能夠估計負載並有效率地分配查詢。
  • 增加故障保護的涵蓋範圍
    ​如果 Dispatcher 沒有收到來自例項的回應,就會自動將請求轉送給其他例項。因此,如果某個例項無法使用,唯一的影響是網站速度變慢,與失去的運算能力成正比。但是所有服務都將繼續。
  • 您也可以從同一個靜態 Web 伺服器上管理不同的網站。
雖然負載平衡可以有效率地分散負載,但快取可有助於降低負載。因此,在設定負載平衡之前,請嘗試最佳化快取並降低整體的負載。良好的快取可以提高負載平衡器的效能,或不需要進行負載平衡。
雖然單一 Dispatcher 通常能夠讓可用的 Publish 例項的容量達到飽和,但對於某些罕見的應用程式而言,額外平衡兩個 Dispatcher 例項的負載是有必要的。設定多個 Dispatcher 前請先詳加考量,因為額外的 Dispatcher 將增加可用的 Publish 例項的負載,並且很容易就可能會降低大多數應用程式的效能。

Dispatcher 如何執行負載平衡

效能統計資料

Dispatcher 會保留內部統計資料,瞭解 AEM 每個例項處理檔案的速度。Dispatcher 會根據此資料,估計在回應請求時哪個例項可提供最快的回應時間,藉此來保留該例項所需的運算時間。
不同類型的請求可能會有不同的平均完成時間,因此 Dispatcher 允許您指定文件類別。然後在運算時間估計值時加以考量。例如您可以區分 HTML 頁面和影像,因為此二者的一般回應時間會有所不同。
如果您使用複雜的搜尋功能,則可建立新的搜尋查詢類別。這可幫助 Dispatcher 將搜索查詢傳送給回應速度最快的例項。藉此來避免速度較慢的例項收到數個「昂貴」的搜尋查詢時停頓下來,而其他例項反而收到「較便宜」的請求。

個人化內容 (黏著連線)

黏著連線可確保同一個使用者的文件都是在 AEM 的同一個例項上撰寫。如果您使用個人化頁面和工作階段資料,這一點就很重要。資料會儲存在同一例項上,因此來自相同使用者的後續請求都必須傳回給該例項,否則資料會遺失。
由於黏著連線會限制 Dispatcher 最佳化請求的功能,因此您應該視需要來使用。您可以指定包含「黏著」文件的檔案夾,如此可確保該檔案夾中的所有文件都是針對每位使用者在相同例項上所撰寫。
針對使用黏著連線的大部分頁面,您必須關閉快取功能,否則無論工作階段內容為何,對所有使用者而言頁面看起來都一樣。
對於​
少數
​應用程式而言,可以同時使用黏著連線和快取;例如如果顯示將資料寫入工作階段的表單。

使用多個 Dispatcher

您可以透過複雜的設定來使用多個 Dispatcher。例如您可以使用:
  • 一個 Dispatcher 在內部網路上發佈網站
  • 另一個 Dispatcher 位於不同的位址下,並具有不同的安全設定,以便在網際網路上發佈相同的內容。
在這種情況下,請確定每個請求只通過一個 Dispatcher。Dispatcher 不會處理來自其他 Dispatcher 的請求。因此,請確定兩個 Dispatcher 都直接存取 AEM 網站。

搭配使用 Dispatcher 與 CDN

內容傳遞網路 (CDN) (例如 Akamai Edge Delivery 或 Amazon Cloud Front) 會從接近使用者的位置傳遞內容。藉此可
  • 加速使用者的回應時間
  • 卸除伺服器的負載
CDN 為 HTTP 基礎架構元件,其運作方式與 Dispatcher 類似:當 CDN 節點收到請求時,會盡可能從其快取中提供請求 (該資源可在快取中取得並且有效)。否則,會前往下一個最近的伺服器,為進一步的請求擷取資源並加以快取 (如適用)。
「下一個最近的伺服器」要取決於您的特定設定。例如在 Akamai 設定中,請求可採取下列路徑:
  • Akamai Edge 節點
  • Akamai Midgres 層
  • 防火牆
  • 您的負載平衡器
  • Dispatcher
  • AEM
在大多數的情況下,Dispatcher 是下一個最近的伺服器,可從快取中提供檔案,並影響傳回至 CDN 伺服器的回應標頭。

控制 CDN 快取

CDN 從 Dispatcher 重新擷取前,有許多方法可控制 CDN 快取資源的時長。
  1. 明確設定 視 MIME 類型、副檔名、請求類型等,設定 CDN 快取保存特定資源的時長。
  2. 到期日和快取控制標頭 如果是由上游伺服器傳送,大部分的 CDN 都會遵守
    Expires:
    Cache-Control:
    HTTP 標頭。例如可藉由使用 mod_expires Apache 模組來達成。
  3. 手動失效 CDN 可透過 Web 介面從快取中移除資源。
  4. API 型失效 大部分的 CDN 也提供 REST 和/或 SOAP API,可從快取中移除資源。
在一般的 AEM 設定中,只要設定副檔名和/或路徑 (可透過上述第 1 和第 2 點達成),即可為經常使用的資源 (例如設計影像和用戶端程式庫) 設定合理的快取期限。部署新版本時,通常需要手動失效。
如果將此方法用於快取受管理的內容,則表示只有在已設定的快取期限到期,並且已再次從 Dispatcher 中擷取文件後,使用者才能看到內容變更。
為了達到更精細的控制,API 型的失效允許您在 Dispatcher 快取失效時將 DN 的快取判定為失效。您可以根據 CDN API 來實作您自己的 ContentBuilder TransportHandler (如果 API 不是 REST 型) ,並設定複寫代理程式,將 CDN 的快取判定為失效。
另請參閱 AEM (CQ) Dispatcher 安全性和 CDN+瀏覽器快取 ,以及關於 Dispatcher 快取 的相關錄製簡報。

將 Dispatcher 與 Author 伺服器搭配使用

如果您搭配使用 AEM 和 Touch UI ,則​
不得
​快取 Author 例項內容。如果已為 Author 例項啟用快取,則需要停用並刪除快取目錄的內容。如要停用快取,應編輯
author_dispatcher.any
檔案並修改區段
/rule
屬性
/cache
如下:
/rules { /0000 { /type "deny" /glob "*"} }
Dispatcher 可用於 Author 例項之前,以改善編寫效能。如要設定編寫 Dispatcher,請執行以下操作:
  1. 在 Web 伺服器中安裝 Dispatcher (可以是 Apache 或 IIS web 伺服器,請參閱 安裝 Dispatcher )。
  2. 您可能希望根據正在運作的 AEM Publish 例項來測試新安裝的 Dispatcher,以確保已達成基準正確安裝。
  3. 現在,請確定 Dispatcher 能夠透過 TCP/IP 連接到您的 Author 例項。
  4. 將範例 dispatcher.any 檔替換為 Dispatcher 下載內容 隨附的 author_dispatcher.any 檔。
  5. 在文字編輯器中開啟
    author_dispatcher.any
    ,並進行下列變更:
    1. 變更
      /hostname
      /renders
      區段的
      /port
      ,以指向您的 Author 例項。
    2. 變更
      /cache
      區段的
      /docroot
      ,以指向快取目錄。如果您正在搭配使用 AEM 和 Touch UI ,請參閱上述警告。
    3. 儲存變更。
  6. 刪除您在上面設定的
    /cache
    >
    /docroot
    目錄中的所有現有檔案。
  7. 重新啟動 Web 伺服器。
請注意,在提供的
author_dispatcher.any
設定中,當您安裝 CQ5 功能套件、Hotfix 或應用程式程式碼套件時,如果
/libs
/apps
下的任何內容受到影響,則您必須刪除調度程式快取中在這些目錄下的快取檔案,以確保下次請求時會擷取新升級的檔案,而非舊的快取檔案。
如果您使用先前設定的作者調度程式並啟用
調度程式排清代理程式
,則請執行以下操作:
  1. 在您的 AEM Author 例項上刪除或停用​
    作者調度程式的
    ​排清代理程式。
  2. 依照上述新指示,重新執行作者調度程式設定。