Dispatcher 版本独立于 AEM。您可能是在单击以前版本的 AEM 文档中嵌入的 Dispatcher 文档链接后重定向到此页面。
Dispatcher 是 Adobe Experience Manager 与企业级 Web 服务器结合使用的缓存和负载平衡工具。
部署 Dispatcher 的过程与所选的 Web 服务器和操作系统平台无关:
要更好地了解如何将 Dispatcher 与 AEM 配合使用,请执行以下操作:
根据需要使用以下信息:
Dispatcher 最常见的用法是缓存来自 AEM 发布实例的响应,从而提高面向外部发布的网站的响应速度和安全性。大部分讨论主要介绍这种情况。
但是,Dispatcher 也可以用于提高创作实例的响应速度,尤其是在有大量用户编辑和更新网站的情况下。有关这种情况的详细信息,请参阅下面的将 Dispatcher 与作者服务器一起使用。
有两种基本方法可进行 Web 发布:
Dispatcher 可帮助实现既快速又动态的环境。它在静态 HTML 服务器(比如 Apache)中使用的目的是:
这意味着:
如同在静态 Web 服务器上一样快速而简便地处理静态内容。此外,还可使用为静态 Web 服务器提供的管理和安全工具。
根据需要生成动态内容,完全没有必要再减慢系统速度。
Dispatcher 包含根据动态站点内容生成和更新静态 HTML 的机制。您可以详细指定将哪些文档存储为静态文件,哪些文档始终通过动态方式生成。
此部分阐明此过程背后的原理。
一个静态 Web 服务器(如 Apache 或 IIS)为网站的访客提供静态 HTML 文件。仅创建一次静态页面,因此对于每个请求都传送相同的内容。
此过程简单而又高效。如果访客请求某个文件(如 HTML 页面),则直接从内存取得该文件;在最差的情况下,从本地驱动器读取它。静态 Web 服务器问世已很久,因此有许多用于管理和安全管理的工具,而且它们与网络基础结构集成得很好。
如果使用 CMS(全称为内容管理服务器,如 AEM),则有一个先进的布局引擎处理来自访客的请求。该引擎从存储库读取内容,并与样式、格式和访问权限相结合,将内容转换为专门根据访客的需求和权利定制的文档。
通过此工作流,可创建更丰富的动态内容,从而提高网站的灵活性和功能性。但是,布局引擎需要比静态服务器更大的处理能力,因此,如果许多访客同时使用系统,则此设置的速度可能会减慢。
缓存目录:对于执行缓存,Dispatcher 模块利用 Web 服务器的功能来提供静态内容。Dispatcher 将缓存文档放在 Web 服务器的文档根目录下。
如果没有配置 HTTP 标头缓存,则 Dispatcher 仅存储页面的 HTML 代码 - 它不会存储 HTTP 标头。如果在网站内使用不同的编码,由于可能会丢失这些页面,所以此场景可能会成为一个问题。要启用 HTTP 标头缓存,请参阅配置 Dispatcher 缓存。
将 Web 服务器的文档根目录放在网络连接存储 (NAS) 上导致性能下降。此外,如果在多个 Web 服务器之间共享位于 NAS 上的文档根目录,则执行复制操作时可能会出现间歇性锁定。
Dispatcher 在一个与所请求的 URL 相同的结构中存储缓存的文档。
文件名的长度可能在操作系统级别受限。也就是说,如果您的 URL 含有大量选择器。
Dispatcher 有两种主要的方法可在对网站作出更改时更新缓存内容。
在内容更新中,有一个或多个 AEM 文档发生了变更。AEM 向 Dispatcher 发送联合请求,以相应地更新缓存:
应注意以下几点:
自动失效可自动使部分缓存失效 - 不会实际删除任何文件。在每次内容更新时,都会处理所谓的 statfile,因此其时间戳记可以反映最新的内容更新日期。
Dispatcher 有一个遵循自动失效机制的文件列表。当请求该列表中的文档时,Dispatcher 会将缓存文档的日期与 statfile 的时间戳记进行比较:
同样,应当注意这几点:
您可以在配置文件中定义 Dispatcher 缓存的文档。Dispatcher 根据可缓存文档列表检查请求。如果文档不在此列表中,则 Dispatcher 从 AEM 实例中请求该文档。
在以下情况下,Dispatcher 始终直接从 AEM 实例请求文档:
?
”。此场景一般指示无需缓存的动态页面,如搜索结果。GET 或 HEAD(针对 HTTP 标头)方法可由 Dispatcher 缓存。有关响应标头缓存的其他信息,请参阅缓存 HTTP 响应标头部分。
Dispatcher 将缓存文件存储在 Web 服务器上,当做静态网站的一部分。如果用户请求一个可缓存的文档,则 Dispatcher 检查该文档是否存在于 Web 服务器的文件系统中:
为确定文档是否为最新状态,Dispatcher 将执行两个步骤:
不自动失效的文档留在缓存中,直至真正删除这些文档为止。例如,网站上的内容更新使其失效。
负载平衡就是在多个 AEM 实例间分发网站的计算负载。
您将获得:
提高了处理能力:
在实践中,提高处理能力意味着 Dispatcher 可在若干 AEM 实例之间分摊文档请求。由于现在每个实例处理的文档数量减少,您的响应速度将会加快。Dispatcher 保留每个文档类别的内部统计信息,以便能够估计负载并高效分发查询。
扩大了防故障范围
如果 Dispatcher 没有从某个实例收到响应,则它自动将请求转发到其他实例。如果一个实例变得不可用,唯一的影响就是网站响应变慢,而这与损失的计算能力成比例。但是,所有服务都继续正常运转。
您还可以在同一个静态 Web 服务器上管理不同的网站。
负载平衡可以有效分布负载,而缓存有助于减少负载。因此,在设置负载平衡之前,请尝试优化缓存并降低整体负载。良好的缓存机制可能会提高负载平衡器的性能,或者弃用不必要的负载平衡。
虽然单个 Dispatcher 即可耗尽可用的发布实例的容量,但对于某些罕见的应用程序而言,在两个 Dispatcher 实例之间平衡负载也可能有意义。需慎重考虑是否配置多个 Dispatcher,因为额外的 Dispatcher 可能会增大可用的 Publish 实例上的负载,并因此可能很容易降低大多数应用程序的性能。
Dispatcher 保留有关 AEM 每个实例处理文档的速度的内部统计信息。Dispatcher 根据这些数据估算哪个实例在应答请求时的响应速度最快,然后它在该实例上预留必要的计算时间。
不同类型的请求,其平均完成时间可能也不相同,因此 Dispatcher 让您指定文档类别。随后将在估算时间时考虑这些类别。例如,可区分 HTML 页面与图像,因为二者的典型响应时间可能相差较大。
如果使用详细搜索功能,则可为搜索查询创建类别。此方法有助于 Dispatcher 将搜索查询发送到响应最快的实例。它还有助于防止速度较慢的实例在收到若干“高成本”搜索查询而其他实例获得“低成本”请求时发生停滞。
粘性连接可确保同一个用户的文档全部在 AEM 的同一个实例上撰写。如果您使用个性化的页面和会话数据,则这一点非常重要。数据存储在该实例上,则同一用户发出的后续请求必须返回到该实例,否则数据就会丢失。
由于粘性连接会限制 Dispatcher 优化请求的能力,因此应仅在需要时使用。您可以指定包含“粘性”文档的文件夹,从而确保该文件夹中每个用户的所有文档都在同一个实例上撰写。
对于使用粘性连接的大多数页面,必须关掉缓存 - 否则无论会话内容是什么,所有用户都将看到相同的页面内容。
对于少数应用程序,可以同时使用粘性连接和缓存;例如,显示将数据写入会话的表单。
在复杂设置中,您可以使用多个 Dispatcher。例如,您可以使用:
在这种情况下,请确保每个请求只通过一个 Dispatcher。一个 Dispatcher 不能处理来自另一个 Dispatcher 的请求。因此,请确保两个 Dispatcher 都能直接访问 AEM 网站。
内容交付网络 (CDN)(如 Akamai Edge Delivery 或 Amazon Cloud Front)从距离最终用户较近的站点交付内容。这样,它可以
CDN 作为一个 HTTP 基础结构组件,其工作方式很像 Dispatcher。当 CDN 节点收到请求时,如有可能(可在缓存中找到资源,并且资源有效),则它从其缓存为该请求服务。否则,它将连接下一个距离最近的服务器,以检索资源并缓存下来,以备响应后续请求(如果适用)。
“下一个距离最近的服务器”取决于您的具体设置。例如,在 Akamai 设置中,请求可以遵循以下路径:
Dispatcher 一般就是下一个可能从缓存提供文档并影响返回到 CDN 服务器的响应标头的服务器。
有若干方法可控制 CDN 缓存某个资源多久后再从 Dispatcher 重新获取该资源。
显式配置
根据 mime 类型、扩展名、请求类型等,配置特定资源在 CDN 缓存中保留多久。
到期和缓存控制标头
如果上游服务器发送 Expires:
和 Cache-Control:
HTTP 标头,则大多数 CDN 都将采用这些标头。例如,可使用 mod_expires Apache 模块实现此方法。
手动失效
CDN 允许通过 Web 界面从缓存中删除资源。
基于 API 的失效
大多数 CDN 还提供使得可从缓存中删除资源的 REST 和/或 SOAP API。
在典型的 AEM 设置中,按扩展名和/或路径进行配置(可通过上述第 1 点和第 2 点实现)使得可为经常使用但不经常变更的资源(如设计图像和客户端库)设置合理的缓存期限。在部署新版本时,通常需要手动进行失效操作。
如果将此方法用于缓存受管内容,则意味着仅在配置的缓存期限到期且再次从 Dispatcher 中获取文档后,内容变更才对最终用户可见。
为了更精细地控制,通过基于 API 的失效,可在 Dispatcher 缓存失效时使 CDN 的缓存失效。可根据 CDN 的 API 实现您自己的 ContentBuilder 和 TransportHandler(如果 API 不基于 REST),并设置使用这两项使 CDN 的缓存失效的复制代理。
另请参阅 AEM (CQ) Dispatcher 安全性和 CDN+浏览器缓存和有关 Dispatcher 缓存的录制演讲。
如果使用具有触屏 UI 的 AEM,请不要缓存创作实例内容。如果为创作实例启用了缓存,则必须禁用缓存并删除缓存目录的内容。要禁用缓存,请编辑 author_dispatcher.any
文件并修改 /cache
部分的 /rule
属性,如下所示:
/rules
{
/0000
{ /type "deny" /glob "*"}
}
Dispatcher 可在创作实例之前使用以提高创作性能。要配置创作 Dispatcher,请执行以下操作:
将 Dispatcher 装入 Web 服务器(Apache 或 IIS Web 服务器,请参阅安装 Dispatcher)。
对照正常工作的 AEM 发布实例测试新安装的 Dispatcher。这样做确保安装的基准正确无误。
现在,确保 Dispatcher 能够通过 TCP/IP 连接到您的创作实例。
将示例的 dispatcher.any
文件替换为随 Dispatcher 下载提供的 author_dispatcher.any
文件。
在文本编辑器中打开 author_dispatcher.any
,并进行以下更改:
/renders
部分的 /hostname
和 /port
,以使其指向您的创作实例。/cache
部分的 /docroot
,以使其指向缓存目录。如果您将 AEM 与 Touch UI 一起使用,请查看上面的警告。删除您在前面配置的 /cache
> /docroot
目录中的所有现有文件。
重新启动 Web 服务器。
对于所提供的 author_dispatcher.any
配置,在安装影响 /libs
或 /apps
下的任何内容的 CQ5 功能包、修补程序或应用程序代码包时,必须删除 Dispatcher 缓存中在这些目录下缓存的文件。这样做可以确保下次请求它们时获取新升级的文件,而不是旧的缓存文件。
如果用过以前配置的创作 Dispatcher 并启用了 Dispatcher 刷新代理,请执行以下操作: