Get best of the week

Turbo页面内容系统的排列方式：方案，事实和一些历史



根据《每日电讯报》的报道，俄罗斯每天将近30％的移动互联网用户无法下载网站。但是，原因可能不仅是覆盖范围不均匀，还可能是页面的“重量”过多。

我们无法影响连接的质量，但是为了帮助网站管理员简化网站的内容，请使其变得更容易-为什么不呢？因此，Yandex中出现了Turbo页面技术：放置所需的所有内容都转移到了我们的内容系统中，并将这些数据转换为便捷的资料。

这个魔术如何运作？成为完整的Turbo页之前的数据路径是什么？我叫Stas Makeev，我领导技术Turbo页面的开发。现在，我将尝试解释所有内容。

但是首先，它只是一个摘要，这样当我开始深入研究细节时，您就不会迷路。

Turbo页面系统的一个主要优点是可以将数据从原始形式快速转换为最终形式：新闻站点的材料在发布后的第一分钟内需求最大，在线商店的商品卡应及时更新，并始终与当前的可用性状态相对应。第二个重要参数是可靠性：内容系统应尽可能稳定，能够承受单个服务器乃至整个数据中心的故障。当然，重要的是要防止连接到Turbo页面的合作伙伴的主机上的负载过大。也就是说，在设计服务时，必须以某种方式在数据处理速度和请求数量增加之间找到平衡。

网站所有者有几种连接到系统的方法：

  • . : YML — -, RSS – ;
  • API: ( );
  • : - .

内容系统将其工作结果存储在“键值”类型的特殊存储中（键值存储或KV存储），其中键是原始站点的URL，该值存储Turbo页面的内容。数据进入此KV存储后，下一个Turbo页面将立即可供搜索用户使用，并且在Yandex服务中，相应的文档带有带有火箭的特殊图标。另外，为了加快工作速度，我们将图片和视频缓存在CDN中。

一个非常简化的一般工作方案如下所示：



一切如何开始


内容系统的第一个版本的安排非常简单：按照时间表，每隔几分钟，就会在Yandex内部云服务器上启动相同的程序。它由几个步骤组成，每个步骤都在为我们所知道的所有提要准备好先前的数据之后运行：

  • RSS feed列表已下载，文档解析器已启动；
  • 从解析器结果中提取图像列表；
  • 尚未将缓存的图片加载到CDN中；
  • 已处理的文档被倒入KV存储库中。

当系统处理数千个新闻机构的RSS提要（总计-大约少于100,000个文档的信息）时，这种方案非常有效。但是，随着提要数量的增加，很快发现了一个问题：每个步骤花费的时间越来越多，在原始来源中出现新文档和以Turbo模式显示文档之间存在延迟。

我们借助各种技巧设法使情况得到控制：我们要做的第一件事是将第一步（下载RSS feed和文档解析器）选择到一个单独的过程中。也就是说，一个正在处理上一个迭代的图片时，另一个过程已经在下载下一个供稿。一段时间后，事实变得很清楚：以这种形式，系统很难扩展。我们需要根本上新的东西。

在新的内容系统中处理RSS，API和YML


旧内容系统的主要问题是所有数据都是一起处理的：直到每个文档都通过了上一个文档，才过渡到下一步。为了消除这一点，决定建立一条特定的管道：让提要和单个文档尽可能独立地处理。所有步骤都分离到单独的服务多维数据集中-在顶层，该方案如下所示：



  • 第一个多维数据集下载RSS提要并继续传递；
  • 第二个-一个接一个地馈送，解析内容。在出口-单独的文件；
  • 第三-一次拍摄一个文件，处理图片和视频，并将所有内容记录在KV存储中。

相同的提要不仅可以在Turbo中注册，还可以在我们的其他服务中注册-例如在新闻或市场中。如果他们每个人都自己下载数据，则网站管理员服务器上的负载将比允许的负载高出几倍。好吧下载提要一次，然后将内容分发给所有消费者服务-Yandex.Robot做到了。我们使用他的服务上载内容：从Yandex.Webmaster那里获取在Turbo中注册的RSS和YML提要的列表，然后将其传输到Robot并订阅下载结果。

在收到的数据上，启动解析器。为了以防万一，让我提醒您：RSS提要只是“ .XML”格式的文件，可以通过合作伙伴的主机上的静态URL进行访问。该文件包含有关站点上所有更新的信息-哪些文档是新文档，哪些文档已更改。理想的提要中只有最近几个小时的最新信息：每数百千字节不超过100个文档。

现实问题：有时文件在Feed中的时间很长，而且从未更改。在这种情况下如何避免重新处理？我们计算每个文档的哈希值，将其存储在数据库中，直到哈希值更改为止，不执行任何操作。

从内容系统的角度来看，处理YML提要和API实际上与与RSS交互没有区别：对于YML，我们启动另一个解析器，并且通过API传输的数据直接从Yandex.Webmaster获得。



图像和视频处理


在解析器的输出处接收到的文档几乎准备好写入KV存储。发送之前剩下要做的唯一一件事就是处理图像和视频：在CDN中缓存并替换文档中的链接。在这里，我们再次向机器人寻求帮助。

首先，我们检查每个图片和视频：它们是否在CDN中？如果所有内容都已缓存，请替换链接并将更新的文档发送到KV存储库。除此以外：

  • 我们会将缺少的URL列表发送给机器人，以进行规划和下载；
  • 该文档本身已存储在临时存储中，因此请稍后再检查一次。

此时，另一个多维数据集接收下载结果，将数据上载到CDN并更新数据库。

在这样的方案中，可以解决与计划有关的另一个重要问题：机器人了解从不同主机下载数据的速度有多快，并且不允许过载。



新文档遵循的典型路径：

  • 该文档出现在提要中。
  • 机器人下载提要；
  • 解析器发现一个新文档并进一步发送它；
  • 我们检查数据库中没有提到文档中的图片，请下载，然后将文档发送到临时存储区（延迟）。当文档在那里时，Robot会下载图片，然后将图片缓存在CDN中，链接会显示在数据库中；
  • , CDN, KV-.
  • : , Delay.


还有另一种连接到Turbo页面的方法，网站管理员无需执行任何操作-Autoparser。它基于内容站点的源数据构建Turbo页面。您可以在Yandex.Webmaster中进行连接，查看完成页面的示例，配置广告和分析。

AutoParser面临的主要困难是通过HTML标记识别在构建Turbo页面时应使用哪些基本信息。为此，我们有几个脱机流程，它们试图确切地了解如何解析特定主机。我将主要关注两个方面：

  • 首先 RSS- HTML- . — , RSS- ( ), . , . CatBoost , , . , , , . , . , , , HTML . ? : . – , .
  • : .. , , , , — . — .

顺便说一句，还有一个更常见的障碍-许多站点阻止了robots.txt中机器人下载图像的功能。不幸的是，无法解决此问题，并且自动解析器不适用于此类页面。

结果，内容系统的完整方案如下所示：



该系统具有很好的可伸缩性：现在大量资源用于服务数据库，自动解析器和系统的其他组件（仅负责解析RSS，YML和API的多维数据集使用300多个处理器）核心），并且在负载增加的情况下，连接额外的容量不会太困难。

感谢您阅读到底！我希望在掌握了这些材料之后，在Turbo页面的工作中，您将获得更多的逻辑和更少的魔力（顺便说一下，这里-有关Turbo页面的更多详细信息）。如果仍然无法理解，请在评论中写-我们保持联系。

More articles:


All Articles