Dispatcher缓存 — 基本原则

Dispatcher用作缓存Http — 负载平衡器

Dispatcher是什么?为什么它最初被称为“Dispatcher”?

Dispatcher是

  • 首先是缓存

  • 反向代理

  • 用于Apache httpd webserver的模块,用于为Apache的多功能性添加AEM相关功能,并与所有其他Apache模块(例如SSL甚至SSI包含,我们将在后面看到)一起平稳运行

在Web的早期,一个网站可能会有几百个访客。 一个Dispatcher的设置可以“分派”请求,也可以平衡多个AEM发布服务器的请求负载,这样通常就足够了 — 因此,该名称为“Dispatcher”。 但是,这种设置已经不再经常使用。

我们将在本文后面看到设置Dispatcher和Publish系统的各种方式。 首先,我们来了解一些http缓存基础知识。

Dispatcher缓存的基本功能

Dispatcher缓存的基本功能

此处解释了Dispatcher的基础知识。 Dispatcher是一个简单的缓存反向代理,能够接收和创建HTTP请求。 正常的请求/响应周期如下所示:

  1. 用户请求页面
  2. Dispatcher会检查它是否已具有该页面的渲染版本。 假设这是对此页面的第一个请求,并且Dispatcher找不到本地缓存副本。
  3. Dispatcher从Publish系统请求页面
  4. 在Publish系统上,页面通过JSP或HTL模板渲染
  5. 页面将返回到Dispatcher
  6. Dispatcher将缓存页面
  7. Dispatcher会将页面返回到浏览器
  8. 如果再次请求同一页面,则可以直接从Dispatcher缓存中提供该页面,而无需在Publish实例上重新渲染该页面。 这节省了在Publish实例上等待用户和CPU周期的时间。

我们在最后一节中谈到“页面”。 但同样的方案也适用于其他资源,如图像、CSS文件、PDF下载等。

数据缓存方式

Dispatcher模块利用托管Apache Server提供的工具。 HTML页、下载和图片等资源作为简单文件存储在Apache文件系统中。 就是这么简单。

文件名由所请求资源的URL派生。 如果您请求文件/foo/bar.html,该文件例如存储在/var/cache/docroot/foo/bar.html下。

原则上,如果所有文件都进行了缓存,因而静态存储在Dispatcher中,则可以拉取Publish系统的插件,而Dispatcher将充当一个简单的Web服务器。 但这只是为了说明原则。 现实生活要复杂得多。 您不能缓存所有内容,而且缓存永远不会完全“满”,因为由于渲染过程的动态性,资源数量可能是无限的。 静态文件系统的模型有助于粗略了解Dispatcher的功能。 并且它有助于解释Dispatcher的限制。

AEM URL结构和文件系统映射

要更详细地了解Dispatcher,让我们重新访问一个简单示例URL的结构。 让我们看下面的示例,

http://domain.com/path/to/resource/pagename.selectors.html/path/suffix.ext?parameter=value&otherparameter=value#fragment

  • http表示协议

  • domain.com是域名

  • path/to/resource是资源存储在CRX中的路径,随后存储在Apache Server的文件系统中

从这里,AEM文件系统与Apache文件系统之间有些不同。

在AEM中,

  • pagename是资源标签

  • selectors表示Sling中使用的多个选择器以确定资源的呈现方式。 URL可以具有任意数量的选择器。 它们以句点分隔。 例如,选择器部分可能类似于“french.mobile.fancy”。 选择器只能包含字母、数字和破折号。

  • html作为最后一个“选择器”称为扩展。 在AEM/Sling中,它还会部分确定渲染脚本。

  • path/suffix.ext是一个类似路径的表达式,可以作为URL的后缀。 可以在AEM脚本中使用它来进一步控制资源的呈现方式。 稍后我们将提供有关此部分的完整部分。 目前,了解您可以将其用作附加参数应该已经足够。 后缀必须具有扩展名。

  • ?parameter=value&otherparameter=value是URL的查询节。 它用于将任意参数传递给AEM。 无法缓存包含参数的URL,因此应限制仅使用绝对必需的参数。

  • #fragment,URL的片段部分未传递到AEM,它仅在浏览器中使用;在JavaScript框架中作为“路由参数”使用,或者跳转到页面上的特定部分。

在Apache中(引用以下图表),

  • pagename.selectors.html在缓存的文件系统中用作文件名。

如果URL具有后缀path/suffix.ext,则

  • pagename.selectors.html已创建为文件夹

  • path pagename.selectors.html文件夹中的文件夹

  • suffix.extpath文件夹中的文件。 注意:如果后缀没有扩展名,则不会缓存文件。

从Dispatcher获取URL后 文件系统布局

从Dispatcher获取URL后​ 文件系统布局

基本限制

URL、资源和文件名之间的映射非常简单。

不过,你可能注意到一些陷阱,

  1. URL可能会变得很长。 在本地文件系统上添加/docroot的“路径”部分很容易超出某些文件系统的限制。 在Windows上的NTFS中运行Dispatcher是一项挑战。 不过,使用Linux是安全的。

  2. URL可以包含特殊字符和变音。 这通常不是Dispatcher的问题。 但请记住,URL会在应用程序的多个位置进行解释。 我们经常会看到某个应用程序表现出奇怪的行为 — 只是为了找出一段很少使用的(自定义)代码未经过彻底测试而出现的特殊字符。 如果你可以的话,你应该避开他们。 如果做不到,请计划全面测试。

  3. 在CRX中,资源包含子资源。 例如,一个页面将具有多个子页面。 这在文件系统中无法匹配,因为文件系统具有文件或文件夹。

不缓存不带扩展名的URL

URL必须始终具有扩展名。 不过,您可以在AEM中处理不带扩展名的URL。 这些URL将不会缓存在Dispatcher中。

示例

http://domain.com/home.html是​ 可缓存

http://domain.com/home是​ 不可缓存

当URL包含后缀时,将应用相同的规则。 后缀需要具有扩展才能缓存。

示例

http://domain.com/home.html/path/suffix.html是​ 可缓存

http://domain.com/home.html/path/suffix是​ 不可缓存

您可能会问,如果资源部分没有扩展名,但后缀有扩展名,会出现什么情况? 在这种情况下,URL完全没有后缀。 查看下一个示例:

示例

http://domain.com/home/path/suffix.ext

/home/path/suffix是资源的路径……因此URL中没有后缀。

结论

始终将扩展添加到路径和后缀。 了解SEO的人有时会辩称,这会在搜索结果中将你排在后面。 但是,未缓存的网页速度会非常慢,排名会进一步下降。

冲突的后缀URL

假定您有两个有效的URL

http://domain.com/home.html

http://domain.com/home.html/suffix.html

它们在AEM中绝对有效。 在本地开发计算机上,您不会看到任何问题(没有Dispatcher)。 在UAT或负载测试中,您很可能也不会遇到任何问题。 我们面临的问题是如此微妙,以至于通过了大多数测试。 当您处于高峰期并且处理时间有限、可能没有服务器访问权限或资源无法修复它时,它将给您带来沉重打击。 我们在那里……

那么……有什么问题吗?

文件系统中的home.html可以是文件或文件夹。 但并非两者都与AEM中的情况相同。

如果您先请求home.html,则将其创建为文件。

home.html/suffix.html的后续请求返回有效结果,但由于文件home.html在文件系统中“阻止”该位置,因此无法再次创建home.html作为文件夹,因此不会缓存home.html/suffix.html

文件系统中的文件阻止位置阻止缓存子资源

文件系统中的文件阻止位置阻止缓存子资源

如果反过来,首先请求home.html/suffix.html,然后先将suffix.html缓存在文件夹/home.html下。 但是,当您随后请求home.html作为资源时,此文件夹会被删除并替换为文件home.html

当父级作为资源获取时删除路径结构

当父级作为资源获取时删除路径结构

因此,缓存的结果完全是随机的,取决于传入请求的顺序。 让事情变得更加棘手的是,您通常有多个调度程序。 此外,在不同的Dispatcher中,性能、缓存命中率和行为可能会有所不同。 如果您想了解网站无响应的原因,您需要确保查看的是包含不幸缓存顺序的正确Dispatcher。 如果你正在查看的Dispatcher幸运地拥有更有利的请求模式,那么你将迷失在寻找问题的过程中。