Recuperación y redundancia

​

Introducción

Al consumir datos en streaming, maximizar tu tiempo de conexión y recibir todos los datos que coinciden con tus filtros es un objetivo fundamental. Esto significa que es importante aprovechar las conexiones redundantes, detectar automáticamente las desconexiones, reconectarte rápidamente y tener un plan para recuperar los datos perdidos.

En esta guía de integración, hablaremos sobre diferentes funciones de recuperación y redundancia: conexiones redundantes, backfill y recuperación.  

Conexiones redundantes

Una conexión redundante simplemente te permite establecer más de una conexión simultánea al stream filtrado. Esto proporciona redundancia al permitirte conectarte al mismo stream con dos consumidores independientes, recibiendo los mismos datos a través de ambas conexiones. De este modo, tu app cuenta con una conmutación por error en caliente para diversas situaciones, como si un stream se desconecta o si falla el servidor principal de tu aplicación.

Actualmente, el stream filtrado solo permite que los Projects con acceso Enterprise se conecten a un máximo de dos conexiones redundantes. Para usar un stream redundante, simplemente conéctate a la misma URL que usas para tu conexión principal. Los datos de tu stream se enviarán a través de ambas conexiones.

​

Recuperación de datos perdidos tras una desconexión: Backfill

Después de detectar una desconexión, tu sistema debería ser lo suficientemente inteligente como para reconectarse al stream. Si es posible, tu sistema debería tomar nota de cuánto tiempo duró la desconexión para que puedas usar la función de recuperación adecuada para rellenar (backfill) los datos. 

Si estás usando un Project con acceso Enterprise y has identificado que la desconexión duró cinco minutos o menos, puedes usar el parámetro de backfill, backfill_minutes. Si envías este parámetro con tu solicitud GET /tweets/search/stream, recibirás las Publicaciones que coincidan con tus reglas dentro de los últimos uno a cinco minutos. Por lo general, entregamos primero estas Publicaciones antiguas antes que cualquier Publicación nueva que coincida y tampoco eliminamos Publicaciones duplicadas. Esto significa que si estuviste desconectado durante 90 segundos, pero solicitas dos minutos de datos de backfill, recibirás 30 segundos de Publicaciones duplicadas, lo cual tu sistema debería poder tolerar. Aquí tienes un ejemplo de cómo podría verse una solicitud con el parámetro de backfill:

curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN"

Si no tienes acceso Enterprise, o has identificado que el tiempo de desconexión fue superior a cinco minutos, puedes utilizar el endpoint de búsqueda reciente recent search endpoint o la función de recuperación para solicitar los datos perdidos. Sin embargo, ten en cuenta que los endpoints de búsqueda de Publicaciones no incluyen los operadores sample:, bio:, bio_name: o bio_location:, y presentan ciertas diferencias en el comportamiento de coincidencia cuando se usan acentos y signos diacríticos con los operadores keyword y #hashtag. Estas diferencias pueden significar que no recuperes por completo todas las Publicaciones que podrían haberse recibido a través de los endpoints de filtered stream. 

Recuperación de datos perdidos tras una desconexión: Recovery

Si estás usando un Project con acceso Enterprise, puedes usar la función Recovery para recuperar datos perdidos dentro de las últimas 24 horas si no puedes reconectarte dentro de la ventana de 5 minutos de backfill.

La función de recuperación de streaming te permite tener una ventana de backfill ampliada de 24 horas. Recovery te permite “reproducir” el periodo de tiempo de los datos perdidos. Un stream de recuperación se inicia cuando realizas una solicitud de conexión usando los parámetros de solicitud start_time y end_time. Una vez conectado, Recovery volverá a transmitir el periodo de tiempo indicado y, a continuación, se desconectará.  

Podrás realizar 2 solicitudes concurrentes a Recovery al mismo tiempo, es decir, “dos trabajos de recuperación”. Recovery funciona técnicamente de la misma manera que el backfill, excepto que se define una hora de inicio y una hora de finalización. Un periodo de recuperación corresponde a un único rango de tiempo.

Name	Type	Description
start_time	date (ISO 8601)	YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Fecha en UTC que indica la hora de inicio desde la que se va a recuperar.
end_time	date (ISO 8601)	YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Fecha en UTC que indica la hora de finalización hasta la que se va a recuperar.

URL de ejemplo de solicitud: https://api.x.com/2/tweets/search/stream?start_time=2022-07-12T15:10:00Z&end_time=2022-07-12T15:20:00Z