CloudFlare主页上的视频承诺，"即使你的服务器宕机了"，我们也会让你的网页保持在线，这是一个我们称之为"永远在线"的功能，当它工作时，它是神奇的。问题是，总是在线并不总是有效的。这篇博文是为了宣布我们刚刚发布了Always Online的一个新版本，我们相信这个版本会使这个功能明显的更好。但是，在我开始之前，让我告诉你一点关于"永远在线"的历史，直到最近它是如何运作的，以及为什么它总是不起作用。然后我将转向我们所做的来创建Always Online v.2。偶然的特征在启动CloudFlare之前，我和Lee运行了蜜罐项目。蜜罐项目的网站是由数据库驱动的，包含了几乎无限多的页面。我们面临的最大挑战之一不是人类流量，它遵循可预测的浏览模式，因此可以可靠地缓存，而是处理来自自动爬虫程序的流量。这些爬虫，不管是合法的（比如谷歌的机器人）还是非法的（比如垃圾邮件收集者），都倾向于"深入"到网站中。结果，它们会命中不太可能在一段时间内被爬网的页面，并且在这样做时，会给数据库带来很大的负载。我以前写过关于网络爬虫对网络性能的隐藏税。

在HoneyPot项目中，Lee构建了许多复杂的缓存策略，以帮助减轻站点数据库上自动爬虫程序的负载。在CloudFlare，他意识到我们可以提供相同类型的缓存，以减轻机器人给后端带来的负担。本质上，我们会自动缓存短时间内的内容，并且，如果内容自上次来自bot的请求后没有更改，则可以在不增加web应用程序负担的情况下交付内容。效果很好。在构建bot内容缓存的过程中，Lee意识到他可以实现其他东西：一个在源服务器发生故障时为页面的静态版本提供服务的系统。使用人工流量来建立这样的缓存是很危险的，因为你不想将一个用户的私人信息暴露给另一个用户（例如，当一个用户访问其银行的网站查看其对账单，然后向另一个用户显示该对账单时，我们无法缓存）。然而，搜索引擎爬虫是构建站点缓存的完美匿名用户。逻辑是：如果它在Google中，那么它已经被有效地缓存了。很好，不完美使用已知的搜索引擎bot流量来构建CloudFlare缓存的方法很聪明，但也存在一些问题。首先，CloudFlare在世界各地运行多个数据中心，每个数据中心的缓存是不同的。解决方案是找到搜索引擎爬虫流量最大的数据中心，如果本地数据中心的缓存中不存在页面的副本，则返回"主"数据中心。在我们的例子中，我们的弗吉尼亚州阿什本数据中心接收的爬网流量最大，因此我们在那里添加了更多的磁盘，并用它来建立始终在线的缓存。这对某些网站很有效，但对于其他网站，当服务器离线时，我们的缓存中仍然没有内容。奇怪的是，页面越是静态，它就越不可能出现在我们的缓存中。解释是缓存数据的来源：搜索引擎爬虫。这些爬虫程序通常设置为访问经常更改的页面，以及很少偶尔更改的页面。如果页面返回304"Not Modified"响应，则内容不会被修改。我们没有通过自动过期一段时间后缓存。

最终的结果是，当某人的站点离线时，他们的访问者看不到页面的缓存版本，而是看到一个CloudFlare错误页面，告诉他们该站点处于离线状态，没有可用的缓存版本。这成为我们的用户和访问他们网站的人的最大抱怨之一。当我们的支持团队将该功能命名为"总是离线"时，我们知道是时候改进它了。版本2我们在缓存页面的方式上做了很多改进，以提高总是在线的性能，但是我们所做的最大的改变是我们自己开始主动抓取页面。CloudFlare现在运行一个爬虫程序，如果客户启用了"始终在线"功能，它会定期对客户的页面进行爬网。爬虫程序的useragent是：Mozilla/5.0（兼容；CloudFlare AlwaysOnline/1.0；+)您可以通过访问以下站点了解爬虫的行为：。我们在"始终在线"中刷新页面的频率取决于您的计划。我们每9天抓取一次免费客户，一次专业客户每3天一次，每天为企业和企业客户服务。我们正在修补我们花在每个网站上的时间，以及调整爬虫程序，以确保它不会访问网站时，他们的负载或其他任何额外的负担。考虑到我们现在可以精确地控制Always Onlinecache中的内容，我们的下一个迭代将把控制权交给我们的用户，并允许您"锁定"您想要确保始终可用的页面，并"排除"您不希望缓存的任何页面。同时，我们使用每个站点最流行部分的数据来选择缓存中要优先处理的页面。我们的目标是让网站离线错误成为过去。我们几天前就开始构建新的缓存，并希望所有始终在线的人在接下来的几天内都能有一个更健壮的缓存可用。虽然每个人都希望他们的源服务器永远不会宕机，但随着总是在线的v.2，我们很高兴能提供更好的安心，以防它曾经这样做。