Dispatcher 綜覽

Dispatcher是Adobe Experience Manager的快取和/或負載平衡工具，可與企業級Web伺服器搭配使用。

部署dispatcher的程式與所選的Web伺服器和作業系統平台無關：

1. 瞭解 Dispatcher (本頁)。另請參閱調度程式的常見問題集。
2. 根據Web伺服器文檔安裝受支援的Web伺服器。
3. 在 Web 伺服器上安裝 Dispatcher 模組，並相應地設定 Web 伺服器。
4. 設定 Dispatcher (dispatcher.any 檔案)。
5. 設定 AEM，如此一來內容更新即可讓快取失效。

視需要使用下列資訊:

• Dispatcher 安全性檢查清單
• Dispatcher知識庫
• 最佳化網站以提升快取效能
• 使用具有多個網域的 Dispatcher
• 將 SSL 與 Dispatcher 搭配使用
• 實作需要權限的快取
• 疑難排解 Dispatcher 問題
• Dispatcher 熱門問題常見問題集

為何要使用 Dispatcher 實作快取?

網路出版的基本方式有兩種:

• 靜態 Web 伺服器: 例如 Apache 或 IIS，都非常簡便而快速。
• 內部管理伺服器: 提供動態且即時的智慧型內容，但是需要較多的運算時間和其他資源。

Dispatcher 有助於實現快速和動態的環境。這可當成是靜態 HTML 伺服器 (例如 Apache) 的一部分，但其目的是：

• 以靜態網站的形式，盡可能儲存 (或「快取」) 網站內容
• 儘可能減少存取版面引擎。

這表示:

• 處理靜態內容​的速度和簡便性與在靜態 Web 伺服器上完全相同；此外，您可以使用可用於靜態 Web 伺服器的管理和安全工具。

• 動態內容​會視需要產生，除非絕對需要，否則並不會讓系統變慢。

Dispatcher 包含的機制可根據動態網站上的內容來產生和更新靜態的 HTML。您可以詳細指定要將哪些文件儲存為靜態檔案，哪些一律動態產生。

本節說明這背後的原理。

靜態 Web 伺服器

靜態 Web 伺服器 (例如 Apache 或 IIS) 會為網站的訪客提供靜態 HTML 檔案。靜態頁面只需建立一次，之後會針對每項請求傳送相同的內容。

此過程非常簡單，因此非常有效率。如果訪客要求檔案 (例如 HTML 頁面)，則通常會直接從記憶體擷取檔案，不然頂多是從本機磁碟讀取檔案。靜態 Web 伺服器已上市相當長一段時間，因此已經有多種管理和安全管理工具，並且與網路基礎架構高度整合。

內容管理伺服器

如果您使用的是內容管理伺服器 (例如 AEM)，進階版面引擎會處理訪客的請求。引擎會從存放庫讀取內容，並結合樣式、格式和存取權限，將內容轉換為符合訪客需求和權限的文件。

這可讓您建立更豐富的動態內容，進而提高網站的彈性和功能。不過，版面引擎比靜態伺服器需要更強大的處理能力，因此，如果有許多訪客使用系統，此設定可能會讓速度緩慢。

Dispatcher 如何執行快取

快取目錄​針對快取，Dispatcher 模組會使用 Web 伺服器的功能提供靜態內容。Dispatcher 會將快取的文件置於 Web 伺服器的文件根目錄中。

快取方法

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 類型)。
• 驗證標頭已設定 (這可以設定)

確定是否已快取文件

Dispatcher 會將快取的檔案儲存在 Web 伺服器上，就像是靜態網站的一部分一樣。如果使用者請求可快取文件，Dispatcher 會將檢查該文件是否存在於 Web 伺服器的檔案系統中：

• 如果已快取該文件，則 Dispatcher 會將檔案傳回。
• 如果未快取，則 Dispatcher 會從 AEM 例項要求該文件。

確定文件是否為最新版本

為了要瞭解文件是否為最新版本，Dispatcher 會執行下列兩個步驟:

1. 它會檢查文件是否會自動失效。如果不會，則可將該文件視為最新版本。
2. 如果文件已設定為會自動失效，Dispatcher 會檢查其是否比最後一次可用變更來得舊或更新。如果版本較舊，Dispatcher 會請求來自 AEM 例項的最新版本，並取代快取中的版本。

負載平衡的優點

「負載平衡」是將網站的運算負載分配至數個 AEM 例項的作法。

其優點如下:

• 提高處理能力​在實務中，這表示 Dispatcher 會與數個 AEM 例項共用文件請求。由於每個例項現在要處理的文件數量較少，因此您的回應時間就會變快。Dispatcher 會保留每個文件類別的內部統計資料，以便能夠估計負載並有效率地分配查詢。

• 增加故障保護的涵蓋範圍​如果 Dispatcher 沒有收到來自例項的回應，就會自動將請求轉送給其他例項。因此，如果某個例項無法使用，唯一的影響是網站速度變慢，與失去的運算能力成正比。但是所有服務都將繼續。

• 您也可以從同一個靜態 Web 伺服器上管理不同的網站。

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的快取失效。

將 Dispatcher 與 Author 伺服器搭配使用

/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，以指向快取目錄。如果您正搭配觸控式UI🔗使用AEM，請參閱上述警告。
   3. 儲存變更。

6. 刪除您在上面設定的 /cache > /docroot 目錄中的所有現有檔案。

7. 重新啟動 Web 伺服器。

1. 在您的 AEM Author 例項上刪除或停用​作者調度程式的​排清代理程式。
2. 依照上述新指示，重新執行作者調度程式設定。