Introdução
Ao consumir dados em streaming, maximizar o tempo de conexão e receber todos os dados correspondentes é um objetivo fundamental. Isso significa que é importante aproveitar conexões redundantes, detectar desconexões automaticamente, reconectar rapidamente e ter um plano para recuperar dados perdidos. Neste guia de integração, discutiremos diferentes recursos de recuperação e redundância: conexões redundantes, backfill e recuperação. Conexões redundantes Uma conexão redundante simplesmente permite estabelecer mais de uma conexão simultânea ao stream filtrado. Isso oferece redundância ao permitir que você se conecte ao mesmo stream com dois consumidores distintos, recebendo os mesmos dados por ambas as conexões. Assim, seu App tem um failover em tempo real para várias situações, como quando um stream é desconectado ou quando o servidor principal do seu aplicativo falha. Atualmente, o stream filtrado permite apenas que Projetos com acesso Enterprise se conectem a até duas conexões redundantes. Para usar um stream redundante, basta se conectar à mesma URL usada para sua conexão primária. Os dados do seu stream serão enviados por ambas as conexões.Recuperando dados perdidos após uma desconexão: Backfill
Depois que você detectar uma desconexão, seu sistema deve conseguir se reconectar ao stream. Se possível, ele deve registrar por quanto tempo a desconexão durou para que você possa usar o recurso apropriado de recuperação e fazer o backfill dos dados. Se você estiver usando um Projeto com acesso Enterprise e identificar que a desconexão durou cinco minutos ou menos, poderá usar o parâmetro de backfill, backfill_minutes. Se você enviar esse parâmetro com sua solicitação GET /tweets/search/stream, receberá os Posts que correspondem às suas regras nos últimos um a cinco minutos. Geralmente entregamos esses Posts mais antigos antes de quaisquer Posts recém-correspondidos e não fazemos deduplicação de Posts. Isso significa que, se você ficou desconectado por 90 segundos, mas solicitar dois minutos de dados de backfill, receberá 30 segundos de Posts duplicados, aos quais seu sistema deve ser tolerante. Veja um exemplo de como fica uma solicitação com o parâmetro de backfill:curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN"
Se você não tiver acesso Enterprise ou identificar que o tempo de desconexão foi superior a cinco minutos, pode utilizar o endpoint de busca recente ou o recurso de recuperação para solicitar os dados perdidos. No entanto, observe que os endpoints de busca de Posts não incluem os operadores sample:, bio:, bio_name: ou bio_location:, e apresentam algumas diferenças no comportamento de correspondência ao usar acentos e diacríticos com os operadores de palavra-chave e #hashtag. Essas diferenças podem fazer com que você não recupere completamente todos os Posts que poderiam ter sido recebidos pelos endpoints do stream filtrado.
Recuperando dados perdidos após uma desconexão: Recovery
Se você estiver usando um Projeto com acesso Enterprise, poderá usar o recurso Recovery para recuperar dados perdidos nas últimas 24 horas caso não consiga se reconectar dentro da janela de backfill de 5 minutos.
O recurso de recuperação de streaming permite uma janela de backfill estendida de 24 horas. O Recovery permite “reproduzir” o período de tempo dos dados perdidos. Um stream de recuperação é iniciado quando você faz uma solicitação de conexão usando os parâmetros de solicitação ‘start_time’ e ‘end_time’. Depois de conectado, o Recovery fará o re-stream do período indicado e, em seguida, desconectará.
Você poderá fazer 2 solicitações simultâneas de recuperação ao mesmo tempo, ou seja, “dois jobs de recuperação”. O Recovery funciona tecnicamente da mesma forma que o backfill, exceto que são definidos um horário de início e um de término. Um período de recuperação corresponde a um único intervalo de tempo.
| Nome | Tipo | Descrição |
| start_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Data em UTC indicando o horário de início a partir do qual recuperar. |
| end_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Data em UTC indicando o horário de término até o qual recuperar. |