Visão geral
Ao consumir dados de streaming, maximizar o tempo de conexão e receber todos os dados correspondentes é um objetivo fundamental. Isso requer:- Aproveitar conexões redundantes
- Detectar desconexões automaticamente
- Reconectar rapidamente
- Ter um plano para recuperar dados perdidos
Conexões redundantes
Uma conexão redundante permite estabelecer mais de uma conexão simultânea a um stream. Isso fornece redundância ao conectar-se com dois consumidores separados, recebendo os mesmos dados por ambas as conexões. Benefícios:- Failover rápido se um stream desconectar
- Proteção se seu servidor primário falhar
- Entrega contínua de dados durante a reconexão
Como usar
Basta conectar-se à mesma URL do stream com um segundo cliente. Os dados serão enviados por ambas as conexões.Conexões redundantes estão disponíveis para o acesso Enterprise. O Filtered Stream permite até duas conexões redundantes para projetos Enterprise. Firehose Streams usam um parâmetro
partition para suportar até 20 conexões simultâneas, enquanto o Sample10 (Decahose) suporta até 2 partições. Verifique a documentação do seu endpoint específico para os limites de conexão.Backfill
Depois de detectar uma desconexão, seu sistema deve rastrear quanto tempo a desconexão durou para determinar o método de recuperação apropriado.Para desconexões de 5 minutos ou menos
Use o parâmetro backfill ao reconectar para receber Posts correspondidos durante o período de desconexão.
Exemplos de solicitações:
Filtered Stream:
Considerações importantes:
- Posts mais antigos geralmente são entregues primeiro, antes dos Posts recém-correspondidos
- Posts não são deduplicados — se você ficou desconectado por 90 segundos mas solicita 2 minutos de backfill, você receberá 30 segundos de Posts duplicados
- Seu sistema deve tolerar duplicatas
- Backfill está disponível com acesso Enterprise
Recovery
Para desconexões que duram mais de 5 minutos, use o recurso Recovery para reproduzir dados perdidos das últimas 24 horas.Como o Recovery funciona
- Faça uma solicitação de conexão com os parâmetros
start_timeeend_time - O Recovery re-transmite o período de tempo especificado
- Ao concluir, a conexão é desconectada
Parâmetros
Exemplo de solicitação
Filtered Stream:Limites do Recovery:
- Disponível para acesso Enterprise
- Janela de recuperação: até 24 horas no passado
- O Filtered Stream permite 2 jobs de recuperação simultâneos
- Firehose, Sample10 (Decahose) e streams firehose específicos por idioma também suportam recovery
- O Sample Stream básico de 1% não suporta recovery; use o endpoint Search em vez disso
Recuperação alternativa: Search
Se você não tem acesso aos recursos de backfill ou recovery, ou se a desconexão excedeu 24 horas, use o endpoint Search Posts para solicitar dados perdidos.Árvore de decisão para recuperação
Boas práticas
- Rastreie a duração da desconexão — Seu sistema deve registrar quando ocorrem desconexões e por quanto tempo duram
- Implemente recuperação automática — Com base na duração da desconexão, escolha automaticamente o método de recuperação apropriado
- Trate duplicatas — Tanto o backfill quanto o recovery podem entregar Posts duplicados; implemente lógica de deduplicação
- Use conexões redundantes — Evite perda de dados mantendo múltiplas conexões quando disponíveis
- Monitore jobs de recuperação — Rastreie o status e a conclusão das operações de recuperação
Próximos passos
Lidando com desconexões
Detecte e trate desconexões
Consumindo dados de streaming
Construa clientes de streaming robustos
Capacidade de alto volume
Lidar com streams de alta taxa de transferência