adobe aem_缓存体系结构（Adobe AEM）–第1部分

adobe aem

缓存 （由Wikipedia定义）是透明存储数据的组件，以便将来对数据的请求可以更快。 我在此假定您将缓存理解为一个组件，并了解缓存周围的任何体系结构模式，因此在这种假设下，本文将不涉及缓存的深入知识。 本文将介绍一些基本的缓存基础知识（无论相关之处），然后深入探讨有关Adobe AEM实施中的内容管理计划的缓存体系结构的观点。

问题陈述

高性能和高可用性的原则没有改变，但是出于对话的考虑，让我们假设我们拥有一个必须满足以下需求的网站。

• 周末有10亿次匹配（匹配是通过对资源的调用定义的，并且包括CSS，JS，图片等静态资源）
• 每天7亿次点击
• 每天有720万页面浏览量
• 每小时220万次页面浏览
• 一秒钟80K次点击
• 一分钟可浏览40K
• 每秒可浏览612次
• 24×7站点可用性
• 正常运行时间99.99％
• 在编辑者发布内容后不到5分钟的时间内，便可以向消费者提供内容

虽然数据看起来很陡峭，但用例并不罕见。 在当今每个人都在使用设备和数字设备的世界中，有些情况下品牌正在开展广告活动。 当这些活动运行时，将需要支持如此之高的负载。 这些负载不会持续很长时间，但是当它们来很快时，它们就变得很厚，我们将不得不对其进行支撑。

作为记录，这不是我正在写的一些随机理论，我有幸参与了一个我们支持类似数字的项目（我无法命名）。

我在这里选择的用例是数字媒体平台，其中大部分内容都是静态的，但是我在这里要讨论的原理将适用于任何其他平台或应用程序。

我们要在这里解决的问题是：

• 性能：缓存是一种模式，我们通过将（已处理的）数据存储在以下存储中来提高应用程序的整体性能：a）最接近数据的使用者，并且b）可以快速访问
• 可伸缩性：如果我们需要使相同的数据集可供系统的各个使用者使用，则将缓存作为一种模式可以使我们更好地扩展系统。 前面讨论过的缓存使我们能够处理数据，而无需一次又一次地运行相同的处理，从而促进了可伸缩性
• 可用性：基于与可伸缩性类似的原理，缓存使我们能够将数据放置在系统/组件可以承受网络或其他组件故障的区域。 尽管这可能会导致在某些时候出现陈旧数据，但最终用户仍然可以使用这些系统。

Adobe AEM观点

Adobe AEM作为应用程序容器（请记住，AEM并不是建立在真正的应用程序容器之上，尽管您可以在一个应用程序容器中进行部署），但它具有细微的可伸缩性。 在本文中，我不会深入探讨可伸缩性方面，但是当您横向扩展AEM发布者时，会导致对操作，许可，成本等方面的担忧增加。我们通过Adobe AEM本身获得的OOTB架构和组件告诉您：利用Web服务器上的缓存（使用调度程序）。 但是，当您必须支持上面列出的非功能需求（NFR）时，标准的OOTB体系结构将需要庞大的基础架构。 我们不能只为CQ设置一些后端服务器和一个带有本地缓存​​的apache前端，并为其提供功能强大的硬件，并希望它将神奇地融合在一起。

正如我所解释的，这个世界上没有魔术，一切都需要通过某种科学来发生。 我们来看一个事实，一个标准的Apache Web服务器可以在一秒钟内处理数千个请求，而当您需要在一秒钟内处理80K命中时，其中包括HTML，JS，CSS，图像等资源。 具有各种尺寸。 在不进行规模调整的情况下，很明显，您将不仅需要服务器集群，还需要服务器场来满足所有流量。 使用服务器场，您将陷入一场噩梦，以围绕运营和维护来建立组织和流程，以确保使站点保持24×7全天候运行。

解

缓存，缓存和缓存

定义

在这里进行设计之前，我们需要了解有关缓存的一些关键方面。 这些概念将在下面的POV中讨论，因此至关重要的是，您必须清楚地了解这些术语。

• 高速缓存未命中是指当流程从高速缓存存储区请求数据而该对象在存储区中不存在时的情况
• 高速缓存命中是指当流程从高速缓存存储区请求数据时数据在存储中可用的情况。 仅当准备好请求的缓存对象时，才发生此事件
• CachePrimeis是一个与过程相关的术语，在该过程中我们用数据填充了缓存存储。 您可以通过两种方式完成此操作
  • Pre-prime是一种方法，我们可以在该方法中主动运行一个进程（通常在应用程序启动时），以加载我们知道可以缓存其状态的所有各种对象。
• 到期是一种机制，允许缓存控制器根据持续时间或事件从内存中删除对象
  • TTL（称为生存时间）是一种方法，用于定义数据可以在计算机上生存的持续时间。
• 当从高速缓存存储器中删除高速缓存对象以优化空间时，驱逐是一种机制

设计//应将数据缓存在何处

这种观点是建立在一个团队的基础之上的，该团队是我为数字媒体平台设计的一部分（我是负载架构师）。 作为品牌正在开展的活动的一部分，我们之前谈到的NFR是我们在周末成功在平台上支持的NFR。 此外，从那时起，我们每次都有此类活动和活动时，都会继续支持非常繁忙的一周。 我们所拥有的设计会照顾架构中的各个缓存层。

本地客户

当我们谈论如此高的流量负载时，我们必须了解，这种流量具有某些有利于我们的特征。

1. 所有这些流量都是由访问网站的一小部分人生成的。 就我们而言，当我们说一个周末提供10亿次点击时，值得注意的是，当天只有300,000位访问者在网站上产生了如此高的负载
2. 所有这些流量中有很大一部分本质上是静态的（这也是数字媒体平台的特性之一）//这些资源的构造（例如javascript，css）以及媒体资产（例如图像和视频）。 这些是曾经部署的文件，很少更改或更改为每天都不会发生的版本
3. 当用户与站点/平台进行交互时，会有内容和数据映射回他们的个人资料和偏好，并且不一定会经常更改，并且这是直接且仅由用户自己管理的

有了这些特征，我们可以将某些东西放到客户端计算机（即浏览器（或设备））上。 分类为客户端缓存的mime类型是图像，字体，css，javascript。 其中一些可以无限缓存，而另一些则应该缓存中等的持续时间，例如几天以及您拥有什么。

Akamai（CDN）

内容交付网络（CDN）是服务提供商，可为最终用户提供高性能和可用性的内容。 要了解有关CDN网络的更多信息，可以在此处阅读。 在整个体系结构中，CDN扮演着至关重要的角色。 Akamai，AWS的CoudFront和CloudFlare是我们与CDN很好集成的一些CDN提供程序。

CDN为我们提供了高度可用的体系结构。 其中一些CDN使您能够配置环境，以便如果原始服务器（指向您的数据中心）不可用，它们将在有限的时间内继续从其本地缓存中提供内容。 这实质上意味着，尽管后端服务可能会关闭，但面向消费者的站点永远不会关闭。 平台的某些方面（如内容交付和新出版物）已激活，在某些情况下（如突发新闻），我们可能会对SLA产生影响，但用户/最终用户永远不会看到您的网站不可用。

在我们的体系结构中，我们使用CDN来缓存所有静态内容，无论是HTML页面，图像还是视频。 通过内容交付网络发布静态内容后，这些页面将在CDN上缓存一定的时间。 这些持续时间是根据刷新持续时间确定的，但是其基本原理是按白金，黄金，白银的层次划分内容，然后分配将被缓存的持续时间。 在NFL这样的平台上，我们将推送游戏供稿分类为“白金”，它们的TTL为5秒，而“首页”，“新闻（非突发新闻）”等内容类型的TTL为10分钟，被归类为黄金。 然后，在同一个项目中，我们的TTL为2小时左右（因此），因此像搜索这样的板块已被分类为Bronze。 目的是要识别并分类所有关键部分（如果不是全部），并确保我们有效利用CDN缓存。

我们已经观察到，即使对于铂金等较短的TTL，随着流量的增加/增加，卸载百分比（定义为CDN所发送的点击数对发送给后端的点击数的平均值）也会增加，并且达到了99.9％的峰值，平均卸载量年龄约为98％。

漆

Varnish是一个Web加速器（如果我可以将其分类为类固醇的Web服务器）。 如果您是第一次听到它的名字，我强烈建议您跳过这里以进一步了解它。

我们引入了Varnish作为一层来解决以下问题：

1. 提高性能（减少服务器数量）–我们意识到Varnish带来了内存加速器，使您的使用Apache的速度提高了5到10倍。 基本上，这意味着您可以使用Apache之上的Varnish处理数倍的负载。 我们进行了严格的测试，以证明这些数字。 x因子主要取决于页面大小，也取决于我们通过网络加载的内容量
2. 避免DoS攻击–我们已经意识到，如果您看到大量流量涌入服务器（定向，有意或任意），并且您无法阻止所有此类流量，则成功阻止流量的机会就很大。与在Apache上进行相同处理相比，不降低服务器的清漆增加了很多倍。 我们还使用Varnish作为一种机制来阻止任何我们不想破坏基础设施的流量，这些流量可能是来自我们所开展的广告系列未针对的市场和地区的蜘蛛和机器人
3. 避免狗堆效应–如果您是第一次听过此词，请跳过此处，不要大肆宣扬：避免狗堆效应 。 在高流量的情况下，即使您已设置CDN网络，当缓存过期时，您的基础结构也会被狗堆打中是很正常的。 当击中较低的TTL时，狗堆效应的机会会增加，并增加。 使用清漆，我们设置了一个称为“宽限配置”的内容，其中不允许相同URL的请求通过。 这些队列，等待一段时间后，如果主请求仍未通过，则随后的请求将由过时的缓存提供服务。

阿帕奇

如果您还没有听说过Apache WebServer，则可能听说过httpd。 如果这些都不响，那么这个（ 欢迎使用！– Apache HTTP Server Project ）将进行解释。 AEM的规模解决方案就是这一层上的东西，众所周知，它是Dispatcher。 这是一个精巧的小模块，可以安装在Apache HTTP服务器上，并充当具有本地磁盘缓存的反向代理。 该模块仅支持一种基于事件的缓存驱逐模型。 我们可以将创作或发布系统配置为在这些服务器上发送删除和使缓存文件无效的事件，在这种情况下，该服务器上的下一次调用将被传递回发布者。 AEM世界中最简单的模型，并且由Adobe之一推荐，是让所有内容都失效（设置statlevelfile = 0或1）。 这种设计简化了页面/组件的设计，因为现在我们不必弄清任何组件间的依赖关系。

尽管这是最简单的事情，但是当我们必须支持如此复杂的需求时，它要求在设计和设置上有一定的技巧。 我建议这样做不是正确的方法，因为它减少了缓存的使用。 我们确保站点层次结构是这样的，即在发布内容时，我们绝不会使整个站点层次结构无效，而仅相关和上下文内容才是被驱逐的内容（对于调度程序而言则是无效的）。

发行人

作为该层蛋糕的最后一层，AEM发布层似乎应该是最简单的事情，并且应该弄清楚。 事实并非如此。 这是您最容易受到伤害的地方（它将在安全带下方）。 AEM的体系结构旨在以特定的方式工作，如果您偏离它，则势必会陷入此陷阱。 您需要注意两件事

1. 当我们开始编写严重依赖查询的组件时，最终将导致系统崩溃。 您应该对AEM查询非常小心（这取决于基础AEM的Lucene实现）。
2. 本文告诉我们，在任何内容都不会影响发布者之前，我们大约有4层缓存。 这意味着应该打到该层的呼叫数量只是微小的数字。 从这里开始，您需要确定您的服务器在一秒钟/分钟内将收到多少呼叫。 我们发现，在大量使用搜索的情况下，AEM支持的TPS引起了轰动。 我在多个项目中都有实例，该实例的数量低于每秒5个事务。

答案是构建某种我们在典型的JEE应用程序中曾经使用过的应用程序缓存。 假设由作者手动或通过摄取手动创建的内容受到限制，这将解决此问题，这意味着可以显着减少我们在搜索上的负担。 您需要注意的警告是，我们将增加一层难以管理的缓存，如果您有发布者集群，则这一层将在服务器之间分布缓存，并可能导致在调度程序上缓存旧页面。 随着打入发布者的呼叫数量增加或群集中服务器数量的增加，发生这种情况的机会也会增加。

翻译自: https://www.javacodegeeks.com/2014/07/caching-architecture-adobe-aem-part-1.html

adobe aem