CDN请求崩溃和 Thundering Herds 问题简化【CDN直播系列2】

请求折叠(Request Collapsing)或折叠转发(Collapse Forwarding)是CDN中一个非常重要的功能，它可以保护CDN和起源服务器不被大量的冗余请求所淹没。

在本文中，我们将深入了解 CDN 缓存命中、未命中的基础知识，然后了解惊群效应(Thundering Herd)和缓存踩踏问题。最后，以对请求折叠或折叠转发的直观理解结束。

什么是缓存命中和缓存未命中

当您在源站服务器和客户端之间放置 CDN 时，本质上，您是在您自己（源站）和客户端之间添加了一个缓存或存储层。CDN 存储普遍请求的内容并在地理上分布，与执行相同工作的原始服务器相比，CDN 可以更快地为您的客户端提供此内容。维基百科的这张插图很好地解释了这一点。

但是，CDN 无法存储原始服务器上存在的所有内容，对吗？CDN 会定期从其缓存中清除请求频率较低的内容。而且，当客户端请求不在 CDN 缓存中的文件时，CDN 将不得不向源站服务器请求该文件。

此时此刻，让我们回顾一下两个重要的 CDN 指标：缓存命中和缓存未命中。

缓存未命中：当客户端向 CDN 请求某些特定内容时发生缓存未命中，而 CDN 尚未缓存该内容。当发生缓存未命中时，CDN 会向源服务器发回请求以获取丢失的内容。当 Origin 响应时，CDN 缓存内容并将其提供给客户端。

缓存命中：当客户端向 CDN 请求某些特定内容并且 CDN 已缓存该内容时，就会发生缓存命中。在这种情况下，CDN 会将内容返回给客户端设备。

好的，通过对 CDN、缓存命中和缓存未命中的旋风式介绍，接下来，让我们了解一些可能对 CDN 产生不利影响的东西。

Thundering Herd 问题或 Cache Stampede 问题

Cache Stampede 或 Thundering Herd 问题很容易想象和理解它可能对 CDN（或更确切地说，任何服务器）造成的损害。

客户端设备从 CDN 请求一个相当大的文件。
在这个阶段有两种可能性——这个文件要么缓存在 CDN 上，要么没有。
假设 CDN 的缓存中没有它，因此它必须从源服务器获取文件。
当 CDN 从源服务器获取文件时，另一个客户端从 CDN 请求相同的文件。
现在，我们面临着一个独特的问题。
- 该文件不在 CDN 的缓存中，并且，
- 遗憾的是，CDN 尚未从源站服务器收到响应其早前请求的文件。

因此，在没有任何高阶智能的情况下，CDN 会再次从源服务器请求相同的文件！

现在，衡量这个问题——

数千个客户端（几乎同时）从 CDN 请求同一个文件。
所有这些都会导致缓存未命中。
而且，CDN 天真地向源服务器发出数千个请求以获取该特定文件。

这听起来不像踩踏事件——可以压垮您的原始服务器吗？类似于 DDoS 攻击，对吧？

这种情况也可能发生在视频流中，而不仅仅是在提供文档或呈现网页的服务器上。例如，它可能发生在

电影的全球首映。
一场风靡一时的直播活动

而且，它也可能发生在多 CDN 配置中，其中多个 CDN 服务于不同的区域，并且所有 CDN 同时开始从源请求相同的文件，彼此之间没有任何通信。

那么，商业 CDN 如何处理这个问题并防止它压垮他们的基础设施？

解决 CDN 中的Thundering Herd/缓存踩踏问题

在 OTT（视频流）中有许多处理 Thundering Herd 或 Cache Stampede 问题的技术。

折叠转发或请求折叠。

折叠转发是 CDN 处理几乎同时发出的多个冗余请求的一种合乎逻辑的方法。在这个方法中，

在第一次缓存未命中时，CDN 联系源服务器并请求文件。
在源可以响应之前，同一文件发生另一个缓存未命中，然后 CDN 将第二个请求添加到队列中并告诉它等待。
CDN 对到达它的同一文件的每个其他请求执行相同的操作（即，在它等待源响应时）。
在源响应文件后，CDN 将其提供给第一个客户端和它存储在队列中的其余客户端。

实际上，CDN 所做的是接收所有请求并将它们“折叠”成一个请求。当源响应文件时，CDN 将文件传送给请求它的所有客户端。

这种技术在 CDN 术语中称为折叠转发或请求折叠。

一些公司将这一概念向前推进，并在 CDN 和源服务器之间添加额外的“源盾”层。这些“源站盾牌”充当额外的缓存层，防止过多的源站行程，并且可以被多个地理分布的 PoP 引用。

将内容预热或预取到缓存中

预热缓存是一种防御技术，其中 CDN 的缓存预加载了预计会传播病毒或有需求的内容。一些 CDN 不允许这样做，因为坦率地说，它可能会破坏 CDN 的目的并使用比实际需要更多的存储空间。

折叠转发的商业实现

大多数流行的 CDN 供应商都以一种或另一种形式实施折叠转发。我在下面链接了一些 CDN 供应商的文档，以及他们的网站/文档中提到折叠转发的一段文本。

请注意，这只是实施了折叠转发的 CDN 供应商的代表性列表，并不详尽！并且，仅供参考，以下文本的所有权利均属于各自的公司。

亚马逊云端
- 引用：“ Origin Shield 是一个集中式缓存层，有助于提高缓存命中率以减少源站的负载。Origin Shield 还通过折叠跨区域的请求来降低您的源站运营成本，因此每个对象只有一个请求到达您的源站。启用后，CloudFront 将通过 Origin Shield 路由所有来源提取，并且仅当内容尚未存储在 Origin Shield 的缓存中时才向您的来源发出请求。”
LimeLight
- 引述：“ ……当一个 Limelight PoP 收到一个没有在本地缓存的内容请求时，它会首先从一个或多个指定的 origin shield PoP 请求内容。如果内容存在于其中一个原始屏蔽 PoP 中，它将被检索并通过 Limelight 的私有骨干网传送到请求的 PoP。只有当源站屏蔽 PoP 的缓存中不存在该内容时，才会将请求转发给源站。这大大减少了对源站的请求，最大限度地降低了源站出口成本，并改善了用户体验。“
Fastly
- 引用：“请求折叠导致单个 Fastly 数据中心内的同时缓存未命中被“折叠”为对源服务器的单个请求。当源正在处理单个请求时，其他请求在队列中等待它完成。”
StackPath
- 引用：“对未缓存内容的多个边缘请求被发送到 Origin Shield，在那里它们被聚合成一个单一的源请求。然后内容被缓存在盾牌上，并进一步分发到请求的边缘位置。”
KeyCDN
- 引用：“启用 Origin Shield 后，当第一个内容请求到达我们的边缘服务器并且该边缘服务器没有缓存内容时，它会将请求传递给我们的盾牌服务器，而盾牌服务器也没有缓存内容。屏蔽服务器将请求传递到您的原始服务器。屏蔽服务器缓存它从您的原始服务器检索到的内容，并将其传递到我们的边缘服务器。最后，我们的边缘服务器将内容传递给客户端。“
Akamai
- 引述：“为了进一步减少原产地之旅，尤其是在流行的直播活动期间，Cloud Wrapper 提供了请求折叠功能。从来源检索时，这会结合多个最终用户请求。结果是更少、更高效的原始请求。”