Recuperación y redundancia

​

Introducción

Al consumir datos en streaming, maximizar el tiempo de conexión y recibir todos los datos que coinciden con tus filtros es un objetivo fundamental. Esto implica aprovechar conexiones redundantes, detectar automáticamente las desconexiones para reconectar con rapidez y contar con un plan para recuperar los datos perdidos.

En esta guía de integración, abordaremos distintas funciones de recuperación y redundancia: conexiones redundantes, backfill y recuperación.  

Conexiones redundantes

Una conexión redundante simplemente permite establecer más de una conexión simultánea al flujo filtrado. Esto aporta redundancia al permitir conectarte al mismo flujo con dos consumidores independientes, recibiendo los mismos datos a través de ambas conexiones. Así, tu App cuenta con un sistema de conmutación por error en caliente para situaciones como la desconexión de un flujo o la caída del servidor principal de tu aplicación.

Actualmente, el flujo filtrado solo permite que los Proyectos con acceso Empresarial se conecten hasta a dos conexiones redundantes. Para usar un flujo redundante, simplemente conéctate a la misma URL que utilizas para tu conexión principal. Los datos de tu flujo se enviarán por ambas conexiones.

​

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

Después de detectar una desconexión, tu sistema debería ser capaz de reconectarse al stream. Si es posible, debería registrar la duración de la desconexión para usar la función de recuperación adecuada y rellenar los datos faltantes.

Si usas un Proyecto con acceso Empresarial y determinaste 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 los Posts que coincidan con tus reglas de los últimos uno a cinco minutos. Por lo general, entregamos primero estos Posts antiguos antes que cualquier Post nuevo coincidente y tampoco realizamos la desduplicación de Posts. Esto significa que si estuviste desconectado durante 90 segundos, pero solicitas dos minutos de datos de backfill, recibirás 30 segundos de Posts duplicados, lo cual tu sistema debería tolerar. Este es un ejemplo de cómo podría verse una solicitud con el parámetro backfill:

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

Si no tienes acceso Empresarial, o determinaste que la desconexión duró más de cinco minutos, puedes utilizar el endpoint de búsqueda reciente o la función de recuperación para solicitar los datos perdidos. Ten en cuenta, sin embargo, que los endpoints de búsqueda de Posts no incluyen los operadores sample:, bio:, bio_name: o bio_location:, y presentan ciertas diferencias en el comportamiento de coincidencia al usar acentos y diacríticos con los operadores keyword y #hashtag. Estas diferencias podrían implicar que no recuperes por completo todos los Posts que se habrían recibido a través de los endpoints de stream filtrado.

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

Si usas un Proyecto con acceso Empresarial, puedes usar la función Recovery para recuperar datos perdidos de las últimas 24 horas si no puedes reconectarte dentro de la ventana de backfill de 5 minutos.

La función de recuperación de streaming te permite contar con una ventana de backfill ampliada de 24 horas. Recovery te permite “reproducir” el período de tiempo de datos perdidos. Se inicia un stream de recuperación cuando realizas una solicitud de conexión usando los parámetros de solicitud ‘start_time’ y ‘end_time’. Una vez conectado, Recovery retransmitirá el período indicado y luego 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 backfill, excepto que se define una hora de inicio y otra de fin. Un período de recuperación corresponde a un único rango temporal.

Nombre	Tipo	Descripción
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 cual 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 cual recuperar.

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