Introducción
Al consumir datos en streaming, maximizar el tiempo de conexión y recibir todos los datos que coinciden con los filtros es un objetivo fundamental. Esto implica aprovechar conexiones redundantes, detectar automáticamente las desconexiones, reconectarse con rapidez y contar con un plan para recuperar los datos perdidos. En esta guía de integración, abordaremos distintas funciones de redundancia y recuperación: conexiones redundantes, backfill y recuperación. Conexiones redundantes Una conexión redundante te permite establecer más de una conexión simultánea al stream filtrado. Esto aporta redundancia al permitirte conectarte al mismo stream con dos consumidores independientes y recibir los mismos datos por ambas conexiones. Así, tu App cuenta con un failover en caliente para diversas situaciones, como la desconexión de un stream o la caída del servidor principal de tu aplicación. Actualmente, el stream filtrado solo permite que los Projects con acceso Enterprise se conecten con hasta dos conexiones redundantes. Para usar un stream redundante, simplemente conéctate a la misma URL que utilizas para tu conexión principal. Los data de tu stream se enviarán por ambas conexiones.Recuperar datos perdidos tras una desconexión: Backfill
Después de detectar una desconexión, su sistema debería ser lo suficientemente robusto como para reconectarse al stream. Si es posible, su sistema debería registrar cuánto duró la desconexión para poder usar la función de recuperación adecuada y backfillear los datos. Si utiliza un Project con acceso Enterprise y determinó que la desconexión duró cinco minutos o menos, puede usar el parámetro de backfill, backfill_minutes. Si envía este parámetro con su solicitud GET /tweets/search/stream, recibirá los Posts que coincidan con sus reglas de entre el último minuto y los últimos cinco minutos. Por lo general, entregamos primero estos Posts más antiguos antes que cualquier Post que coincida posteriormente, y no realizamos desduplicación de Posts. Esto significa que, si estuvo desconectado durante 90 segundos pero solicita dos minutos de datos de backfill, recibirá 30 segundos de Posts duplicados, lo cual su sistema debería tolerar. A continuación, un ejemplo de cómo sería 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 tiene acceso Enterprise, o determinó que la desconexión duró más de cinco minutos, puede utilizar el endpoint de búsqueda reciente o la función de recuperación para solicitar los datos perdidos. Sin embargo, tenga en cuenta que los endpoints de búsqueda de Posts no incluyen los operadores sample:, bio:, bio_name: ni 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 recupere por completo todos los Posts que podrían haberse recibido a través de los endpoints de stream filtrado.
Recuperar datos perdidos tras una desconexión: Recovery
Si utiliza un Project con acceso Enterprise, puede usar la función Recovery para recuperar datos perdidos dentro de las últimas 24 horas si no puede reconectarse dentro de la ventana de backfill de 5 minutos.
La función de recuperación de streaming le permite contar con una ventana de backfill ampliada de 24 horas. Recovery le permite “reproducir” el período de tiempo de datos perdidos. Se inicia un stream de recuperación cuando realiza una solicitud de conexión usando los parámetros de solicitud ‘start_time’ y ‘end_time’. Una vez conectado, Recovery volverá a emitir el período indicado y luego se desconectará.
Podrá realizar 2 solicitudes concurrentes a Recovery al mismo tiempo, es decir, “dos trabajos de recuperación”. Recovery funciona técnicamente del mismo modo que backfill, excepto que se define una hora de inicio y una de finalización. Un período 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 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. |