Cómo está organizado el sistema de contenido de las páginas Turbo: esquemas, hechos y un poco de historia



Según TelecomDaily , casi el 30% de los usuarios de Internet móvil en Rusia diariamente tienen problemas para descargar sitios. Sin embargo, la razón puede estar no solo en una cobertura desigual, sino también en demasiado "peso" de la página.

No podemos influir en la calidad de la conexión, pero para ayudar a los webmasters a simplificar el contenido del sitio, hacerlo más fácil, ¿por qué no? Entonces, la tecnología de las páginas Turbo apareció en Yandex: nuestro sistema de contenido pasa todo lo necesario para su colocación, y convierte estos datos en materiales fáciles y rápidos.

¿Cómo funciona esta magia? ¿Cuál es la ruta de datos antes de convertirse en una página Turbo completa? Mi nombre es Stas Makeev, lidero el desarrollo de la tecnología de las páginas Turbo. Ahora intentaré explicar todo.

Pero primero, es un resumen para que no te pierdas cuando empiezo a profundizar en los detalles.

Una ventaja clave del sistema de páginas Turbo es la conversión rápida de datos del formulario original al final: los materiales de los sitios de noticias son los más solicitados en los primeros minutos después de la publicación, y las tarjetas de los productos de las tiendas en línea deben actualizarse rápidamente y corresponder siempre al estado actual de disponibilidad. El segundo parámetro importante es la fiabilidad: el sistema de contenido debe ser lo más estable posible, ser capaz de sobrevivir al colapso de servidores individuales o incluso de centros de datos completos. Y, por supuesto, era importante evitar una carga excesiva en los hosts de nuestros socios conectados a las páginas de Turbo. Es decir, al diseñar el servicio, era necesario encontrar de algún modo un equilibrio entre la velocidad del procesamiento de datos y el aumento en el número de solicitudes.

Los propietarios del sitio tienen varias formas de conectarse al sistema:

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

El sistema de contenido almacena los resultados de su trabajo en un almacenamiento especial del tipo "clave-valor" (clave-valor-almacenamiento o KV-almacenamiento), donde la clave es la URL del sitio original, y el valor almacena el contenido de la página Turbo. Tan pronto como los datos caigan en este almacenamiento KV, la siguiente página de Turbo estará inmediatamente disponible para los usuarios de búsqueda, y en los servicios de Yandex el documento correspondiente tiene un icono especial con un cohete. Además, para acelerar el trabajo, almacenamos en caché imágenes y videos en nuestros CDN.

Un esquema general de trabajo muy simplificado se ve así:



Cómo todo empezó


La primera versión del sistema de contenido se organizó de manera bastante simple: cada pocos minutos, de acuerdo con el cronograma, se lanzaba el mismo programa en el servidor interno de la nube Yandex. Consistió en varios pasos, cada siguiente ejecución después de que los datos anteriores estuvieran listos para todos los feeds que conocemos:

  • Se descargó la lista de fuentes RSS, se lanzó el analizador de documentos;
  • se extrajo una lista de imágenes de los resultados del analizador;
  • las imágenes no almacenadas en caché se cargaron en el CDN todavía;
  • los documentos procesados ​​se vertieron en el repositorio de KV.

Tal esquema funcionó perfectamente cuando el sistema manejó varios miles de fuentes RSS de agencias de noticias (en total, información sobre un poco menos de 100,000 documentos). Pero con el aumento en el número de alimentaciones, se descubrió rápidamente un problema: cada paso tomó más y más tiempo, aumentó el retraso entre la aparición de un nuevo documento en la fuente original y su visualización en modo Turbo.

Logramos mantener la situación bajo control con la ayuda de varios trucos: en primer lugar, seleccionamos el primer paso (descargar fuentes RSS + un analizador de documentos) en un proceso separado. Es decir, mientras uno procesaba imágenes para la iteración anterior, el otro proceso ya descargaba feeds para la siguiente. Después de un tiempo, quedó claro: de esta forma, el sistema es muy difícil de escalar. Necesitamos algo fundamentalmente nuevo.

Procesamiento de RSS, API y YML en el nuevo sistema de contenido


El principal problema del antiguo sistema de contenido era que todos los datos se procesaban en una sola pieza: no había transición al siguiente paso hasta que cada documento pasara el anterior. Para deshacerse de esto, se decidió construir una cierta tubería: dejar que los feeds y los documentos individuales se procesen de la manera más independiente posible. Todos los pasos se separaron en cubos de servicio separados: en el nivel superior, el esquema resultó así:



  • el primer cubo descarga canales RSS y pasa;
  • el segundo: toma los feeds uno por uno, analiza el contenido. A la salida: documentos separados;
  • el tercero: toma documentos de uno en uno, procesa imágenes y videos, graba todo en el almacenamiento KV.

Los mismos feeds se pueden registrar no solo en Turbo, sino también en nuestros otros servicios, por ejemplo, en las Noticias o en el Mercado. Si cada uno de ellos descarga datos por sí solo, la carga en el servidor webmasters será varias veces mayor que la permitida. ¿Cuánta razón? Descargue el feed una vez y luego distribuya el contenido a todos los servicios al consumidor: Yandex.Robot hace esto. Utilizamos sus servicios para descargar contenido: tomamos de Yandex.Webmaster una lista de fuentes RSS y YML registradas en Turbo, la transfieren a Robot y se suscriben a los resultados de la descarga.

En los datos recibidos, inicie el analizador. Por si acaso, permítame recordarle: una fuente RSS es solo un archivo en el formato ".XML", accesible mediante una URL estática en el host del socio. Este archivo contiene información sobre todas las actualizaciones en el sitio: qué documentos son nuevos y cuáles se modifican. Solo la información más actualizada en las últimas horas estaría en las fuentes ideales: no más de 100 documentos por varios cientos de kilobytes.

Mordiscos de realidad: a veces los archivos están dentro del feed durante mucho tiempo y nunca cambian. ¿Cómo evitar el reprocesamiento en tales casos? Calculamos el hash de cada documento, lo almacenamos en la base de datos y no hacemos nada hasta que el hash cambie.

Procesar feeds YML y API desde el punto de vista del sistema de contenido prácticamente no es diferente de interactuar con RSS: para YML, iniciamos otro analizador, y los datos transmitidos a través de la API se obtienen directamente de Yandex.Webmaster.



Procesamiento de imagen y video


El documento que se recibe en la salida del analizador está casi listo para escribir en el almacenamiento KV. Lo único que queda por hacer antes de enviar es procesar las imágenes y videos: almacenar en caché en el CDN y reemplazar los enlaces en el documento. Aquí nuevamente recurrimos al Robot en busca de ayuda.

En primer lugar, verificamos cada imagen y video: ¿están en la CDN? Si todo ya está en caché, reemplace los enlaces y envíe el documento actualizado al repositorio de KV. De otra manera:

  • enviamos la lista de URL faltantes al Robot para su planificación y descarga;
  • el documento en sí está en almacenamiento temporal, así que después de un tiempo intente verificarlo nuevamente.

En este momento, otro cubo recibe los resultados de la descarga, carga los datos en el CDN y actualiza la base de datos.

En dicho esquema, se puede resolver otro problema importante relacionado con la planificación: el robot comprende qué tan rápido es posible descargar datos de diferentes hosts y no permite sobrecargas.



Ruta típica que sigue un nuevo documento:

  • El documento aparece en el feed.
  • El robot descarga la alimentación;
  • el analizador descubre un nuevo documento y lo envía más lejos;
  • comprobamos que las imágenes del documento no se mencionan en la base de datos, ordenamos la descarga, el documento se envía al almacenamiento temporal (Retraso). Mientras el documento está allí, el Robot descarga las imágenes, se almacenan en caché en la CDN y los enlaces aparecen en la base de datos;
  • , CDN, KV-.
  • : , Delay.


Hay otra forma de conectarse a las páginas de Turbo, para lo cual el webmaster no necesita hacer nada: Autoparser. Construye páginas Turbo basadas en los datos de origen del sitio de contenido. Puede conectarse, ver ejemplos de páginas terminadas, configurar anuncios y análisis en Yandex.Webmaster.

La principal dificultad que enfrenta AutoParser es reconocer mediante el marcado HTML qué información básica se debe usar al crear una página Turbo. Para hacer esto, tenemos varios procesos fuera de línea que intentan comprender exactamente cómo analizar un host específico. Me centraré en dos principales:

  • El primero RSS- HTML- . — , RSS- ( ), . , . CatBoost , , . , , , . , . , , , HTML . ? : . – , .
  • : .. , , , , — . — .

Por cierto, un obstáculo más frecuente: muchos sitios bloquean la capacidad de descargar imágenes de robots en robots.txt. Desafortunadamente, es imposible solucionar este problema, y ​​el Autoparser no está disponible para tales páginas.

Como resultado, el esquema completo del sistema de contenido se ve así:



El sistema resultó ser bien escalable: ahora se usa una cantidad significativa de recursos para dar servicio a la base de datos, el autoparser y otros componentes del sistema (solo el cubo responsable de analizar RSS, YML y API usa más de 300 procesadores núcleos), y en caso de aumento de la carga, no será demasiado difícil conectar capacidades adicionales.

¡Gracias por leer hasta el final! Espero que, después de este material, en el trabajo de las páginas Turbo obtengas más lógica y menos magia (por cierto, aquí- Incluso más detalles sobre las páginas Turbo). Si algo sigue siendo incomprensible, escribe en los comentarios, estamos en contacto.

All Articles