第195期 – Saumya Majumder谈Cloudflare故障如何影响网络及WordPress性能解决方案

Nathan Wrigley: 欢迎来到WP Tavern的Jukebox播客。我是Nathan Wrigley。Jukebox是一个专注于WordPress方方面面的播客：人物、事件、插件、区块、主题，以及本期的话题——Cloudflare故障如何影响网络和WordPress性能解决方案。

今天播客的嘉宾是Saumya Majumder。Saumya是BigScoots的首席软件工程师，深耕高性能WordPress工程和先进的Cloudflare驱动架构。在他的职业生涯中，Saumya构建了大规模系统，包括自定义缓存引擎、迁移工具、基于Workers的自动化以及边缘计算解决方案。他在BigScoots扮演了关键角色，监督企业客户，并开发可扩展、对开发者友好的解决方案，不断突破WordPress托管的界限。

我们的对话从一个及时的话题开始：最近一次波及整个互联网的重大Cloudflare故障。Saumya解释了幕后的情况、这类全球基础设施问题的本质，以及为何即使拥有最健壮的系统，某些停机时间也完全不可避免。他提供了宝贵的见解，阐述了BigScoots如何为客户缓解这些问题，甚至在故障期间自动化快速故障转移以保持网站在线。

接着，我们探讨了BigScoots团队正在研究的一些创新，他们专注于网站速度和可靠性。这包括CDN级别的页面缓存，以及他们与Cloudflare企业版的深度集成。Saumya详细解释了这种缓存与传统基于服务器的缓存有何不同，以及它如何确保全球用户能快速、本地化地访问网站内容。

如果你对托管公司如何管理如此先进的缓存策略，以及Cloudflare如何融入托管版图感到好奇，那么本期节目正适合你。

如果你有兴趣了解更多信息，可以前往wptavern.com/podcast查看节目说明中的所有链接，那里也能找到所有其他集数。

话不多说，有请Saumya Majumder。

Nathan Wrigley: Saumya你好，欢迎做客播客。

Saumya Majumder: 嘿，我很好。你好吗？

Nathan Wrigley: 非常好，谢谢。这将是一次有趣的对话。我是通过Tammy Lister联系到Saumya的，她过去一段时间一直在和Saumya沟通。我们原本计划聊聊他们在BigScoots的工作以及他们那些有趣的创新。但纯属巧合，就在我们录制前一天，Cloudflare，我称之为“乐子”吧，Cloudflare给整个互联网带来的乐子发生了。所以我想我们会在播客开始时稍微跑题一下，也谈谈这个意外事件。考虑到你们的工作很大程度上基于Cloudflare，这会很有意思。

不过，你介意先花点时间介绍一下自己吗？告诉我们你是谁，你在目前的角色中做什么，然后我们再深入交谈。

Saumya Majumder: 我是Saumya。我是BigScoots的首席软件工程师，专注于高性能WordPress工程和先进的Cloudflare驱动架构。我还构建大规模系统，从自定义缓存引擎到迁移工具、基于Worker的自动化、边缘计算等等。我也负责我们的企业客户，以及我们所有内部的WordPress项目、插件和知识产权。我还为我们的客户构建可扩展、对开发者友好的解决方案，以确保他们获得最佳的服务产品。

Nathan Wrigley: 非常感谢。我想稍微深入一下这个话题。这听起来技术性极强，但也感觉你很早就走上了一条非常特定的道路。你是如何最终从事所有这些有趣但相当具体的工作的？是你大学毕业后追求的吗？你是如何走上这条路的？

Saumya Majumder: 这其实是个有趣的问题。我记得，在我大学二年级的时候，我开始做课外项目。我开始涉足PHP，那是在WordPress的早期。我进入了WordPress的世界，开始编码、修改东西、向核心提交代码、摆弄WordPress。那是在WordPress生态系统的早期。从那时起，我开始钻研PHP和其他东西。后来，我开始发现问题并思考如何解决。例如，今天很多公司都提供CDN页面缓存，在2025年的今天，这几乎是全球非常普遍的事情。如果你去任何高端托管或任何高级套餐，你都会期望有基于CDN的页面缓存。但要知道，即使在几年前，情况也并非如此。那时是服务器级别的页面缓存或RAM级别的页面缓存，都在服务器上。我和一位因WordPress编码而在线结识的朋友，实际上发明了CDN级别的页面缓存。在那之前，这并不是一个东西。我们创建了一个名为“Super Page Cache for Cloudflare”的插件，后来被一家名为Optimal的公司收购。在那个插件中，我们研究了现有解决方案，剖析了请求的处理方式或互联网的工作原理：你从世界任何地方发出请求，该请求通过光纤电缆等传输到ISP数据中心，然后从那里到达数据中心，最后到达服务器。如果没有缓存，服务器必须生成整个页面，获取响应，再返回给你；如果有缓存……所以我们说，这增加了巨大的延迟，特别是当服务器和你之间的距离较远时。那时已经有MaxCDN、KeyCDN等专注于从CDN提供静态文件的提供商。这已经是一个东西了，但我们想，静态文件从CDN来很好，但真正的飞跃是如果我们能移动页面。也就是说，直接从CDN提供页面HTML。如果你在澳大利亚，请求就不必到美国。如果它被缓存了，它实际上就来自你的附近。缓存一直是我最喜欢解决的复杂问题之一，因为它是计算机工程世界中那些“无法解决”的问题之一。我就是这样进入这个领域的，然后开始了……我搞砸了很多东西，也修复了很多东西，这是一段旅程。很难解释，但这是一段充满失败和一点点成功的旅程。

Nathan Wrigley: 可以想象。你是否有过感觉接近终点的时刻，还是说整个事情就是，我做了这个，然后我知道一周后还会有其他东西可以优化？是否曾有过你对自己说“好了，现在暂时搞定了”的时刻，还是说总是“不，还有另一个东西”？

Saumya Majumder: 这总是一个过程，对吧？技术在发展。有更多更深层次的东西可以挖掘。我们最近发布的一个东西是端到端数据库保护缓存（end DB protection caching），我稍后会谈到，还有登录用户缓存。这两样东西都在我的待办清单上多年了，我做了很多研发工作来确定具体的实现方式。所以，这又是一个过程，需要时间。

Nathan Wrigley: 是的，很好。正如你所说，我们稍后会深入这些细节。但正如我在节目开头所说，纯属巧合，我们经历了这次Cloudflare为整个互联网提供的服务（可以说是）真正崩溃的事件。我想，根据你在世界上的位置和清醒时间，这对欧洲人以及你可能在的世界部分地区来说，正好发生在我们都醒着的时候。如果你在北美，尤其是西海岸，你可能错过了大部分。但在这里，大半天时间里，Cloudflare上的一切都停止工作了。这影响的深远程度非常有趣。我们都听说过这个问题。我们看到过乐高积木搭成的高塔图画，底部有一小块积木支撑着整个东西，它叫Cloudflare，或者叫AWS之类的。你能向我们解释一下昨天到底发生了什么吗？你现在能理解这件事吗？

Saumya Majumder: 是的。互联网是个神奇的东西。它靠魔法运作。如果我要解释它如何工作，那将是另一回事。但它的工作方式，尤其是Cloudflare的情况，是这样的：很多人把Cloudflare看作CDN提供商，像MaxCDN或Akamai或任何其他提供商。但CDN只是Cloudflare的一部分。Cloudflare是一个建立在其之上的巨大服务。因此，当你拥有这样一个协同工作的大系统时，会出现许多关键的依赖关系。你有所有这些盒子，但所有这些盒子都依赖于来自下层某个配置文件或某个东西。如果那一层的东西出了问题，顶层的盒子运行良好，但无法工作，因为下面那层的东西没了。我还想说，在互联网世界里，没有什么是永远不出错的。任何东西都会在某个时间点出问题。无论是谷歌、Azure、AWS、Cloudflare，任何东西都是如此。即使你拥有自己的数据中心和一切，就像我们一样，即使你准备了各种故障转移和备份系统，事情仍然可能出错。也许备份没有启动，也许没有发生。昨天我在Twitter上看到很多梗图，很多人发帖说，嘿，我刚加入Cloudflare互联网团队，我推了一段代码然后就出事了。我理解这很好笑，但当你深入探究时，这其实并不好笑。这真的是红色警报场景。相信我，没有公司希望陷入那种红色警报场景。因为你要明白，所有这些公司也在与许多企业客户打交道，他们向这些客户承诺了100%或99.99%的服务水平协议（SLA）。当他们达不到这个标准时，他们必须向客户支付巨额赔偿。所以这不仅是停机和声誉受损、市场营销等问题，公司还会因此损失真金白银。但是，从技术的工作原理来看，事情可能会搞砸。即使你做了多层代码审查，你仍然会错过某些边界情况，这些情况只会在特定的“这个发生、那个发生”的条件下出现，而这种情况发生的概率可能只有0.00001%。但这0.00001%不是零，它可能发生。在工程世界里，我们称某些事情为超低优先级，认为它永远不会发生。我不是说它不能发生，它可能发生，但概率如此之低，以至于在当前有更关键的事情要做的时候，花费工程时间在这上面并不划算。但有时候事情就是发生了。作为高级工程师，这种事会发生。就Cloudflare而言，因为这是一个如此庞大的系统，即使他们确定了根本原因——假设工程师需要一些时间来找出问题并推送修复——你要明白，很多人正在发送请求，请求正在减少，他们找到了根本原因，推送了修复，然后大量的请求涌向Cloudflare。所以一切稳定下来需要时间。这很糟糕，但任何人如果认为Cloudflare很糟糕，如果我从Cloudflare迁移到X、Y、Z或其他东西，这种事就不会发生……我昨天看到一条推文，有人说，向人们发冷邮件说Cloudflare宕机了。但我们不使用Cloudflare，我们使用自己的VPS和专用服务器。我笑出声来。我理解，你的数据中心没有宕机，但这并不意味着它永远不会宕机。

Nathan Wrigley: 这几乎是必然的。我看到的一个有趣的事情是，在Cloudflare创建的总结性帖子中，提到了这个关于一个意外文件大小翻倍的事情。它本应该是这个大小，但翻倍了，然后传播开来。在一段时间内，其连锁反应是看起来像DDoS攻击。有一段时间看起来可能是恶意行为者所为。所以Cloudflare的工程师们，结果证明，走错了方向。他们朝着错误的方向去寻找问题，这可能增加了几个小时的缓解时间，然后才弄清楚发生了什么。然后，就像你说的，连锁效应是，这不是像关掉电脑再打开那样，Cloudflare就恢复了。这是一个整体的传播过程，你发现问题、修复问题、问题缓解，这大概需要数小时，然后你可以看到停机报告在整个互联网上慢慢恢复。

Saumya Majumder: 你必须明白，正如我所说，Cloudflare，人们认为Cloudflare是一家安全公司或CDN公司。但Cloudflare远不止于此，对吧？他们的CDN骨干网实际上是他们的支柱，是他们构建自己服务的基础。因此，任何时候他们找到他们所谓的“控制平面”的修复，将修复推送到控制平面后，它必须传播到他们所有的边缘节点。Cloudflare拥有数量最多的CDN PoP（接入点）。所以它必须被推送到所有这些地方，重新启动，所有这些疯狂的事情必须发生，一切才能正常运转。然后涌入的流量它必须处理。这是一件疯狂的事情。但我喜欢Cloudflare的一点是，这并不是Cloudflare第一次发生全球性中断。他们以前也有过全球性中断。我非常喜欢Cloudflare的两点。第一是他们超级透明。任何时候出现问题或发生这种情况，他们总是会发布详细的博客文章，解释到底发生了什么，他们做了什么来修复，以及他们如何确保未来不会再发生这种情况。而且未来确实没有再发生。如果你看看他们之前发生的全球性中断，我想是在六月，那次是因为一个叫Cloudflare KV的东西，它依赖于GCP。所以当GCP宕机时，KV就宕机了，结果系统就宕机了。从那以后，他们现在正在努力消除这种依赖，在内部构建东西来确保这种情况不会发生。之前，我想是去年或更早，另一次全球性中断，整个主数据中心宕机了。有多次故障转移，但发电机没启动，这个没启动，那个没启动，导致了巨大的故障转移场景。从那以后，他们确保，好吧，我们现在必须确保那种情况永远不会再出现。所以他们总是在努力确保发生的任何事情不会第二次发生。他们也确实做到了。但归根结底，在技术世界里，事情可能会出错。事情就是这样。

Nathan Wrigley: 但从最终用户的角度来看，这有点令人好奇，稍后你将向我们解释BigScoots内部运作的一些复杂性以及它如何与Cloudflare结合，这会很有趣。但从非技术用户的角度来看，感觉就像天塌下来了，因为互联网的很大一部分崩溃了，许多他们熟悉的东西都出问题了。举几个很多人都会熟悉的例子。例如，如果你是社交网络X的用户，它就完全失效了。那里肯定在某个环节依赖于Cloudflare。还有ChatGPT，现在几乎成为每个人每天都会用到的东西，它也宕机了。然后它波及到许多其他事物。新闻机构宕机。登录各种系统的能力宕机。可能你的平台本身还在工作，但你可能启用了Cloudflare运行的Turnstile验证系统，结果没人能登录你的专有平台，因为Cloudflare的Turnstile部分不工作了等等。所以它产生了巨大的影响。这种令人寒心的影响是，人们然后错误地以某种方式将Cloudflare视为……我不知道，一个需要被整治的巨人。你知道，我们再也不能让这种事情发生了，我们对这些少数大型组织的依赖太多了。但到了今天，每个人都忘记了，他们继续自己的生活，回到了周一的状态。所以我没有什么问题要问，但我想分享一些见解。

Saumya Majumder: 哦，是的，当然。这里有几点非常重要的事情需要理解。首先，正如你所说，在社交媒体上谈论这些事情的人，相信我，要么他们不是（高级）工程师，要么他们不理解问题。所以，每次发生类似事情时，他们都会说同样的话——几周前AWS宕机了，几个月前GCP宕机了，然后他们说，嗯，Facebook宕机了，每次有东西宕机时，他们用的词完全一样。但东西就是可能宕机。你必须接受这一点并继续前进。这就是为什么当你与这些大公司签订企业协议时，他们会有一个SLA协议，就像我早些时候提到的那样。所有这些公司，GCP、AWS、Cloudflare，如果你是他们的重要企业客户，你会与他们签订SLA协议。他们说，好吧，我们保证给你100%的正常运行时间，或99.999999%的正常运行时间。任何时候他们错过了这个标准，他们必须向客户支付巨额资金作为赔偿，意思是，好吧，我们违反了合同，所以这是给你的赔偿。所以你必须明白，任何时候发生这种情况，对公司来说，不仅在市场营销方面是坏事，在财务方面也是坏事。因为你要明白，所有这些大公司都有小客户，也有像大企业客户这样的巨头客户，公司真正担心的是这些巨头客户。对于这些巨头客户，他们必须支付巨额赔偿，因为问题没有在规定时间内解决。所以这不是他们不担心立即解决的问题。他们真的在尽最大努力修复它。话虽如此，现在谈谈你提出的其他几点，Turnstile、WAF和其他东西。正如我所说，Cloudflare不仅是一家安全公司。它是一个庞大的东西。Cloudflare有一个叫“开发者平台”的东西，你实际上可以在上面部署自己的API、AI工作负载、工作流、整个React或整个应用程序。这太棒了。我使用它。我喜欢那个平台。这是使用Cloudflare的一面，还有另一面使用Cloudflare，例如使用BigScoots。假设你有一个托管在BigScoots的WordPress网站，但它是通过Cloudflare代理的，以利用他们的CDN、安全性和所有这些功能。在像WordPress网站这样，你没有使用Cloudflare作为主机的情况下，Cloudflare只是作为代理，确保你的源IP不被暴露，你的网站超级安全，性能好，有CDN等等。在这种情况下，任何时候发生这种问题，你都可以……当这次中断发生时，API仍然在工作，我们实际上为所有客户利用了我们的API，确保任何请求不再通过Cloudflare代理，而是直接前往我们的服务器，直到Cloudflare恢复为止。

Nathan Wrigley: 哦，所以你可以通过API关闭代理。

Saumya Majumder: 是的，通过API。

Nathan Wrigley: 所以，由于Turnstile宕机，我们其他人无法登录，无法通过网络验证进入Cloudflare网络。但API仍然可用，所以你可以为你的许多客户，以及他们的域名和网站关闭代理。哦，这真的很有趣。所以他们只有几分钟的停机时间。好的，这很吸引人。

Saumya Majumder: 所以当我们看到这次中断发生时，任何请求进来，对我们来说也是一个红色警报场景。全员上阵。任何时候有请求进来，人们遇到问题，我们立即启动代理API，确保这个网站上线。这样，请求就不再通过Cloudflare，而是直接到达我们，直到Cloudflare恢复正常。这帮助我们尽可能地为客户减少停机时间，即使Cloudflare在技术上宕机了。但如果你在Cloudflare上托管你的Nuxt、React或Next.js应用程序，使用Cloudflare Workers之类的东西作为主机，那么你就无法推送任何东西。

Nathan Wrigley: 是的，API帮不了你。

Saumya Majumder: 是的。这很糟糕，但它会发生。它可能发生。

Nathan Wrigley: 我想这就是信息所在。人类创造的任何东西都不是永恒的。一切都有崩溃的时刻。但是，如果你回想周一之前，那时一切顺利，Cloudflare正常工作，那么每个人都很满意。然后我们经历了这段时间，大概8小时，每个人都在挥动手臂，在还能工作的社交网络上抱怨。但现在到了周三，那件事早已过去。那艘船已经开走了，不管怎样，继续前进。信心，我想你基本上是说你可以对Cloudflare有信心。他们会有小问题，因为他们像任何其他公司一样，事情会出错。

Saumya Majumder: 任何东西都可能出小问题。所以不仅仅是……你必须明白这一点，对吧？再次强调，我并不是说Cloudflare只是一家CDN提供商，但如果你看看Cloudflare和他们所做的一切，其复杂性是令人难以置信的疯狂。它的复杂度极高。它让事情对你来说超级简单。好吧，你只需打开这个开关，就完成了。但如果你看看引擎盖下，以及它必须经历的所有环节和链条，而这在毫秒间发生，那是极其复杂的。正如我所说，我并不是说Cloudflare不好。我认为Cloudflare很棒，因为两点：他们超级透明，所以任何时候发生任何事情，你提到的博客文章，他们没有隐藏任何事情，比如，哦，这不是我的问题，不做推卸责任的事情。不，不，不。这是我们的问题。这就是问题所在。例如，在那篇博客文章中，他们本可以完全不提DDoS的事情。他们本可以说，哦，这是一个配置文件问题，我们修复了，结束了。但他们没有，他们实际上一步步带你了解他们是如何处理问题的，这真的很棒。然后他们实际上从错误中学习，确保特定的错误永远不会再发生，同时他们正在快速成长，疯狂地构建东西、推送新东西，这对我来说太棒了。

Nathan Wrigley: 我想那篇文章甚至一开始，如果不是第一句话，也肯定是在前一两句话里。类似“我们让你失望了”这样的话。这是完全承担责任，我想。所以为他们鼓掌。你说得对，其背后的复杂性，就像你之前说的，互联网，互联网上任何东西能工作，这完全是计算机工程的一个奇迹。你知道，我们在一个平台上互相看着对方。我可以看到你的图像，你可以看到我的图像，你能听到我的音频，我能听到你的音频。你在星球的另一边，但这就像你站在我身边一样发生着。在这次谈话过程中流动的数百万信息包，这是疯狂的。而Cloudflare在上面又增加了整整一层其他东西，这使它更加疯狂。

Saumya Majumder: 是的。你必须问一个问题，如果它这么糟糕，为什么所有这些大公司都在使用Cloudflare？因为他们正在做一些规模空前的事情，甚至没有人想到。这令人难以置信地疯狂。

Nathan Wrigley: 是的，确实是。所以我们改天再谈这个。但显然，在BigScoots，你们真的把你们的“马车”拴在了Cloudflare上。当你同意来播客和我交谈时，我明显感觉到你的水平和我能跟上的水平非常不同。所以我们将谈谈你在BigScoots的工作。我会尽量跟上，但如果我误解了什么，或者不得不请你重复什么，希望你不要介意。我只是好奇，因为Tammie Lister，就像我在本期开始时说的，她的意见我很尊重，她说你在BigScoots与Cloudflare的连接方面做了一些真正创新、有趣的事情。所以请阐述一下你一直在做的一些有趣的工程工作。我会尽力抓住要点。

Saumya Majumder: 首先，Tammie很棒。Tammie太棒了。但是，我认为BigScoots是托管领域最早利用Cloudflare企业版的公司之一。我知道我们没有像其他主机那样做大量的市场营销，但我们是最早在我们的托管生态系统中利用Cloudflare企业版的。那是在非常早期的时候，当时所有这些事情，这个市场还不存在。所以我们在构建一些人们甚至没有测试过的东西。正如我一开始所说，我和我的一位同事发明了CDN级别的页面缓存。这远在APU（此处可能指某个特定技术或产品）和所有那些东西出现之前。所有这些东西实际上都是建立在我们构建的架构系统之上的，包括APU、Workers等等。在BigScoots，Cloudflare，尤其是Cloudflare企业版为我们打开了一扇全新的大门，因为它现在允许我们为每个用户提供CDN级别的页面缓存，并且缓存命中率超高。我的意思是，每次你点击一个页面，从缓存中获取的概率要高得多，相比免费计划或任何其他计划。这就是开始。在此基础上，我们构建了自己的专有插件，名为BigScoots Cache，它不仅允许你利用和发挥Cloudflare页面缓存的优势，还让你能够微调网页页面缓存的各个方面。

Nathan Wrigley: 我要在这里暂停你一下。首先，我确信几乎所有的听众，因为他们是WordPress用户，都会理解缓存是什么。他们会理解这个记住某些东西以便下次需要时已经准备好的过程。但他们可能不理解Cloudflare在他们的企业版上如何做到这一点。那么，有什么不同？因为我们可能熟悉，我不知道，一个WordPress插件，我们大概知道缓存存在服务器某处的文件中，是一个HTML文件之类的。而你描述的不是在一个位置，而是真正地全球分布，以便在距离某人最近的点就绪。所以请多告诉我们一些。

Saumya Majumder: 让我用一个类比来解释，好吗？在CDN级别页面缓存之前，我想几乎每个人都记得，我们曾经有缓存插件。我不会具体点名，但它们就是缓存插件。当你打开它们时，它们本质上做的是创建一个advanced-cache.php文件。你WordPress安装目录里有这个文件的所有内容。它的作用是，当你发送一个请求时，假设你在澳大利亚，你的服务器在美国，你想打开example.com，这个请求穿过海底到达数据中心，然后到达服务器，服务器收到请求，开始处理，运行所有数据库查询等等，然后获取要显示给你的HTML。那时它会做的是，advanced-cache.php会介入，它会创建HTML的一个副本，存储在服务器本地，这样下次如果有人请求该页面，它就不需要问服务器：请处理PHP和数据库等等，因为它会消耗少得多的服务器资源，因为WordPress就像预热了一样。请求到达advanced-cache.php，然后它说哦，我有那个缓存文件，发送缓存响应给你。但即使在这种情况下，如果你从澳大利亚发出请求，服务器在美国，你必须明白延迟非常高，因为请求必须从澳大利亚到美国，然后无论得到什么，再从美国返回澳大利亚。所以传输时间相当高。从那以后，那时我们在考虑MaxCDN、KeyCDN之类的，把静态文件放在CDN上，这样是的，页面由服务器生成，但静态文件几乎是从你所在的位置提供的。如果你在澳大利亚悉尼，当你请求那个东西时，静态文件来自悉尼。这就是我们想到的：如果我们能把页面HTML放在CDN上，而不是放在服务器上呢？这有两大好处。首先，它速度快得惊人。因为这个页面HTML遍布全球，所以如果你在悉尼发出请求，请求就像，哦，好吧，这个页面缓存给我，给你，响应，你在不到100毫秒内就得到了。对于坐在印度、德国和世界其他地方的人来说，同样的事情也会发生，因为它被缓存在全球各地。所以它不仅仅来自一个地方。任何时候它没有被缓存，请求会到达服务器，HTML被处理，当响应发出时，它就被缓存了。它被缓存到世界各地。这就是页面缓存的部分，对吧？还有其他东西，对象缓存和OPcache，那是另一个完全不同的层次。但我不打算深入那个，因为那样会太长了。这就是对象缓存和Cloudflare企业版发挥作用的地方，对吧？Cloudflare企业版使我们能够确保所有页面以非常高的缓存命中率缓存在全球各地。缓存命中率意味着，当某个东西在某个地方被缓存，假设有人请求那个文件，而那里的缓存过期了，不存在了，那么请求又必须到源站处理再返回给你。这通常是Cloudflare较低级别计划的情况。使用Cloudflare企业版，你可以获得非常高的缓存命中率。所以当它被缓存时，它会在缓存中保存很长时间。除此之外，我们还有分层缓存和区域分层缓存等等疯狂的东西。这意味着我们有分层系统。所以当你发出请求时，请求首先在上层被缓存。当下层……我该如何向你解释呢？假设你在菲尼克斯，好吗？在菲尼克斯有一个数据中心，或者CDN术语中的PoP，但上层PoP在芝加哥。假设有人从芝加哥发出请求，页面被缓存在芝加哥数据中心。现在，由于我们有这个分层缓存系统，当你从菲尼克斯发出请求时，该PoP不是直接向源站发送请求，而是首先在Cloudflare的内网（注意，不是互联网）内部，询问：嘿，上层中有人有这个页面的缓存吗？如果他们说是，他们就从上层获取，这非常快，因为没有流量，这是Cloudflare的内部网络。如果没有，则向上层传递请求，因为只有上层才有权从源站拉取请求。它到达上层。上层从源站拉取，创建一个副本，在上层，然后发送回下层。这样，在这种分层架构中，它确保缓存命中率高得惊人。

Nathan Wrigley: 让我复述一下，以确保我理解了。我脑子里理解的最简单方式是一堆同心圆。中心是我，我希望在外圈找到某个东西。所以我首先要做的是去我的内圈，如果内圈没有，我们需要去下一个外圈，再下一个外圈，再下一个外圈。在旧世界，或者Cloudflare的非企业版中，在某个时刻，我们不得不进一步走出圆环才能找到我们要找的东西。但我想你说的是，在企业级，那个外圈正在不断地将东西推向更本地的内圈。所以不必出去一个圈，又一个圈，又一个圈，它只需跳出一个圈，获取所需，然后直接跳回来。换句话说，每样东西总是比任何其他设置中更近，地理上更近。

Saumya Majumder: 是的，除此之外，如果你看看这种架构的反面，对吧？想象一下你在菲尼克斯，菲尼克斯没有缓存。菲尼克斯向源站发送请求，现在密西西比州的某人发出请求，他们也没有缓存，他们的PoP也发送请求……所有这些PoP都在向源站发送请求，因为他们自己没有本地缓存，这很糟糕，因为这意味着对源站的请求会急剧增加，而我们正试图减少这种情况。但在这种意义上，我们有……想象一下有一组固定的上层数据中心，然后我们有中层，然后是下层，对吧？如果下层没有，它询问中层，中层检查全球任何中层是否有。如果有，立即发送。这发生在Cloudflare的内部网络中，而不是在公共互联网上，明白吗？速度快得惊人。

Nathan Wrigley: 好的。所以，再次原谅我，我要做一个假设，我可能错了。我猜在Cloudflare方面，他们有自己定制的硬件来路由所有这些东西。所以就像你说的，你把它描述为一个互联网内网，几乎，以他们这样的规模。但他们有自己的硬件，能够路由这些信息，大概比你和我可能拥有的速度更快，延迟更低。

Saumya Majumder: 是的，这是一个内网，不是互联网。这是一个私有通道，对吧？除了Cloudflare没人说话。最棒的部分是，想象一下假设你从密西西比州发出请求，而印度孟买有一个上层数据中心，对吧？那么发生的情况是，即使它在美国没有被缓存，它也会看到，好吧，我在孟买有缓存，让我们从那里获取，而不是向源站发出调用，减少了对源站的调用。

Nathan Wrigley: 好的，那部分我不明白。整个网络甚至在其需要之前就知道最近的东西在哪里。我明白了。这很吸引人。他们拥有连接这些东西的电缆吗？Cloudflare拥有连接这些的电缆吗？

Saumya Majumder: 是的。是的，他们有自己的数据中心，自己的骨干网，所有那些。除此之外，在BigScoots，我们甚至与Cloudflare服务有直接的物理连接。这叫做CNI。这是下一步。让我描述一下这个图景。这是你作为用户，对吧？这是Cloudflare坐在中间，充当反向代理，这是源站。它的工作方式是你发出请求，对吧？假设你，一个请求被这个反向代理Cloudflare接收。然后它处理那个东西，是否必须向你显示WAF页面，无论逻辑是什么，对吧？它是否在缓存中？等等。如果它没有被阻止或挑战，我需要显示缓存吗？我在缓存中有它吗？你正在与内部网络交谈，所有这些。这些都发生在中间层，对吧？这个中间层现在连接到他们整个Cloudflare链，对吧？如果，假设孟买有，它从孟买拉取，返回给你。所以请求永远不会到达源站，对吧？现在，无论出于何种原因，你向Cloudflare发出请求，Cloudflare检查其内部网络，它自己也没有，所以它必须向源站发出请求，对吧？有趣的部分在这里。你和Cloudflare之间的这段连接是通过公共互联网发生的，对吧？因为你发出请求，请求通过公共互联网到达Cloudflare，对吧？然后这是你的源站，所以从Cloudflare到源站，这通常也通过公共互联网发生。Cloudflare然后发出请求，该请求通过互联网，到达数据中心。但我们所做的是神奇的部分。由于我们运营并拥有自己的数据中心，我们所做的是，我们实际上用一根物理电缆连接，字面意思就是具有超高带宽的光纤电缆，连接到Cloudflare服务器，连接到我们的服务器。所以发生的情况是，任何时候Cloudflare必须从我们的源站获取某些东西，它不是通过公共互联网发送该请求（这可能很慢，可能有拥塞等等），而是通过我们创建的私有网络，那根私有光纤电缆，直接到达我们的源站。就像，哦，这个托管在BigScoots。我们需要与BigScoots交谈。好的，通过这个通道发送，这不属于公共互联网。然后，砰，它到了那里，返回，速度快得惊人。

Nathan Wrigley: 好的。这是怎么发生的？这是你与Cloudflare达成的某种直接协议吗？感觉你几乎成了他们网络基础设施的第三方部分。

Saumya Majumder: 想象一下，Cloudflare像一个巨大的网络，我们的系统也接入他们的网络，这样他们就可以使用内网系统直接从我们这里获取数据，而不是使用慢得多的公共互联网，那里可能有拥塞等等。使得在Cloudflare代理和源站之间的请求变得极快。

Nathan Wrigley: 那么整个事情是怎么来的？你们是如何达成这个协议的？因为我不知道其他组织是否这样做，在网络托管领域之外，也许这是典型的，你可以遵循另一家公司的路线图。我没听说过这个，所以这有点意思。这种关系是怎么建立的？

Saumya Majumder: 如果你不运营自己的数据中心，很难做到这一点。

Nathan Wrigley: 是的，我没有。

Saumya Majumder: 是的，因为你必须字面上把你的服务器、路由器等连接到Cloudflare网络。所以外面的大多数托管公司，他们不运营自己的数据中心。他们实际上是从其他云提供商那里租赁硬件和服务。而我们运营我们自己的私有云，我们自己的系统，我们自己的数据中心。例如，有些公司可能使用AWS、GCP或Azure，然后创建自己的变体，并通过它运行Cloudflare。所以他们实际上没有对数据中心其他服务器的物理访问权限。而我们有。如果我们看到什么，我们实际上可以拔插驱动器，我们可以在数据中心做事情，我们可以改变东西，我们可以物理连接这些东西，这几乎是我所知道的托管提供商都没有的。

Nathan Wrigley: 这太有趣了。老实说，我们可以没完没了地谈论这个。但基本上，归根结底是，你在让电子的速度尽可能快。在一个分布式网络中，有些东西不知道，有些东西知道。这一切都是为了尝试弄清楚如何让一切以电子飞过遍布世界的光缆的速度知道一切。

Saumya Majumder: 我甚至还没描述服务器。

Nathan Wrigley: 我远未说完，因为我想了解对于使用的人来说是怎样的。我们是一个WordPress播客，所以我想在某个时候我们需要把它融入进去。那么，对于一个拥有WordPress网站的普通人来说，所有这些你创造的聪明技术，以及你在BigScoots与Cloudflare结合的技术，能带来什么好处？

Saumya Majumder: 它带来极快的速度。极快的速度，超级改进的Core Web Vitals，以及超级DDoS防护等等。它带来了所有这些。我不想谈论这类事情，我知道听众可能不感兴趣。我想谈谈用户可以利用的其他更有趣的东西。我刚才在谈论BigScoots Cache，这是我们自己的知识产权，对吧？我们创建了BigScoots Cache插件，用于管理与整个Cloudflare缓存系统协同工作。不仅如此，如果你是一个高级用户，它实际上让你能够微调和管理你想要的缓存系统的每个方面，每个方面。例如，我们默认将CDN缓存TTL设置为比如X，但你有一堆页面，你希望TTL更低。有钩子可以做到。你可以使用它。或者，假设我们有一个智能缓存清除系统。所以每当你发布或更新帖子时，当你按下发布或更新按钮时，在幕后，BigScoots Cache插件不仅智能地清除该特定页面的缓存，它还知道与该文章链接的所有其他重要页面，如分类页面、存档页面、作者页面等，然后也会清除那些页面的缓存。你也可以使用其他钩子。假设你有一些虚假的存档页面，我们见过很多。假设你使用一个主题，你在一个页面上显示文章列表，这从技术上讲是一个页面，你使用了像短代码这样的东西，这不是一个真正的存档页面。所以系统不认为它是一个存档页面，但你想在发布这个标签或这个类别的文章时清除那个页面缓存。有钩子可以做到。你不必自己动手。如果你来找我们，告诉我们，这是我们的问题，这是问题所在，我们实际上可以为你编写代码并为你完成。我们可以为你设置好。我们提供完全托管的系统。

Nathan Wrigley: 所以我猜，你在那个层面需要有相当深入的理解缓存基础设施，或者你所提供的功能是否对任何人都可用，不一定需要部署，但任何人通过翻阅你的文档就能理解吗？还是说相当专业，需要“螺旋桨帽”、锡纸帽那种水平？

Saumya Majumder: 我们为每个钩子都有适当的文档。在最上面我们提到，这是为高级受众准备的。如果你不知道钩子是什么等等，你将很难理解发生了什么。但如果你知道，如果你熟悉操作和过滤器等等，这对你来说会相当简单。所以我说，如果你不知道，但你有问题，这经常发生，人们来找我们，我们实际上只是写一个代码片段，然后为他们实现。所以你不必知道所有那些疯狂的东西。如果你是高级用户，文档在那里；如果你不是，它也在那里。除此之外，BigScoots Cache有自己的REST API，你可以用它来清除缓存。想象一下你构建了一个Laravel系统，或一些后端系统，你在其中为你的电子商务网站添加东西，并且你想清除缓存。当发生时，你实际上可以利用BigScoots Cache REST API来做到这一点。所以这就是BigScoots Cache的终端。然后在我们的BigScoots门户中……

Nathan Wrigley: 啊，那正是我接下来想问的。请继续，是的。

Saumya Majumder: 是的。我认为我们拥有对Cloudflare企业版最先进、最精细的控制，这是业内其他任何人都无法提供的。我不知道你是否看过我们的企业设置页面。我们真的允许用户按照他们想要的方式精确地微调东西。例如，假设你想保护你的登录页面免受恶意机器人和攻击者的侵害，这样他们就不能DDoS它？有一个开关。打开它，就完成了。你想启用我们自己的高级加固生产（这里可能指特定的安全功能），它不是使用Cloudflare的加固生产，而是使用我们自己的专有算法。你想使用它，请便。打开，开关在那里。你想更改你的图片优化设置，去做吧。你想为从缓存设置、速度优化设置开始的所有东西启用Rocket Loader，有很多东西你可以调整。你想阻止AI机器人，去做吧。你想阻止恶意机器人，比如管理、挑战恶意机器人，只需打开一个开关，就完成了。所以我们那里有很多设置。我想，如果你去看看那个设置页面，你会大吃一惊。我们允许客户自定义和微调的所有东西。例如，你想阻止来自某些国家或大陆的请求，现在设置就在那里。只需选择国家或大陆，请求就被阻止了。你想管理、挑战，你不想阻止，你想挑战来自某些国家和大陆的请求，你可以直接进入我们门户内的设置，选择你想要挑战的大陆和国家。所以你可以组合。你想阻止来自这些国家和大陆的请求，挑战来自这些大陆和国家的请求，对其余的不做任何事。所以你可以把玩这个到全新的水平，你可以做任何你想做的事。

Nathan Wrigley: 这绝对吸引人。这让我觉得你的目标受众不会是那些实体店、夫妻店网站？

Saumya Majumder: 实际上他们是。是的，你不会相信我们收到过多少次这样的请求：嘿，你知道，在我们的分析中，我们看到很多来自泰国的请求，这就像打破了我们的工具，所以我想要么挑战要么阻止它。所以我们说，你去设置，选择泰国