O que é uma desconexão?
Estabelecer uma conexão com APIs de streaming significa fazer uma solicitação HTTPS muito longa e analisar a resposta de forma incremental. Ao conectar-se a um endpoint de streaming, você deve formar uma solicitação HTTPS e consumir o stream resultante o máximo possível. Os servidores do X manterão a conexão aberta indefinidamente, salvo:- Erros do lado do servidor
- Atraso excessivo do lado do cliente
- Problemas de rede
- Manutenção rotineira do servidor
- Logins duplicados
Por que as conexões desconectam
Possíveis motivos para desconexões:Erros comuns de desconexão
Operational disconnect
Too many connections
Detectando desconexões
Os endpoints de streaming fornecem um heartbeat de keep-alive de 20 segundos (um caractere de nova linha). Use esse sinal para detectar desconexões:- Seu código deve detectar quando o conteúdo novo e o heartbeat param de chegar
- Se nenhum dado for recebido por 20 segundos, acione a lógica de reconexão
- Alguns clientes HTTP permitem especificar um read timeout — defina-o para 20 segundos
Estratégia de reconexão
Assim que uma conexão estabelecida cair, tente reconectar imediatamente. Se a reconexão falhar, use estratégias de backoff com base no tipo de erro:Erros de rede TCP/IP
Use backoff linear. Esses problemas são geralmente temporários.- Aumente o atraso em 250ms a cada tentativa
- Atraso máximo: 16 segundos
Erros HTTP
Use backoff exponencial para erros HTTP onde a reconexão é apropriada.- Comece com espera de 5 segundos
- Dobre a cada tentativa
- Atraso máximo: 320 segundos
Erros de rate limit (HTTP 429)
Use backoff exponencial com espera inicial maior.- Comece com espera de 1 minuto
- Dobre a cada tentativa
- Cada 429 recebido aumenta o tempo de espera até o rate limiting expirar
Rate limits e uso
As respostas de conexão de streaming retornam três cabeçalhos para ajudá-lo a entender os limites:
Para acompanhar quantos Posts foram entregues, implemente lógica de medição no lado do cliente para que o consumo possa ser medido e pausado se necessário.
Boas práticas de reconexão
Use uma arquitetura de fila FIFO
Seu cliente de stream deve inserir os Posts recebidos em uma fila first-in, first-out (FIFO) ou estrutura de memória semelhante. Um processo/thread separado deve consumir Posts dessa fila para análise e armazenamento. Esse design escala eficientemente quando os volumes de Posts mudam drasticamente.Teste estratégias de backoff
Teste sua implementação de backoff usando credenciais de autorização inválidas e examine as tentativas de reconexão. Uma boa implementação não receberá respostas 429.Emita alertas para múltiplas reconexões
Se seu cliente atingir seu limite superior de tempo entre reconexões, envie notificações para que você possa investigar os problemas de conexão.Trate mudanças de DNS
Certifique-se de que seu processo cliente honre o Time To Live (TTL) do DNS. Algumas stacks armazenam em cache os endereços resolvidos durante toda a duração do processo e não detectarão alterações de DNS dentro do TTL. Cache agressivo leva a interrupções de serviço à medida que o X redistribui a carga entre endereços IP.Defina o cabeçalho User-Agent
Inclua a versão do seu cliente no cabeçalho HTTPUser-Agent. Isso é crítico para diagnosticar problemas do lado do X. Se seu ambiente impedir a definição de User-Agent, use o cabeçalho x-user-agent em vez disso.
Próximos passos
Recuperação e redundância
Recupere dados perdidos após desconexões
Consumindo dados de streaming
Construa clientes de streaming robustos
Capacidade de alto volume
Lidar com streams de alta taxa de transferência