Comunicação assíncrona

A comunicação em um fluxo é assíncrona e bidirecional. Seu cliente envia registros continuamente sem esperar que cada um seja confirmado, e o servidor envia confirmações de volta pela mesma conexão à medida que os registros se tornam duráveis. Esse desacoplamento é o que permite que um único cliente mantenha uma alta taxa de transferência: ele continua enviando enquanto as confirmações chegam em segundo plano.

Offsets e o loop de confirmação

Cada submissão em um fluxo, seja um único registro ou um lote, recebe um deslocamento lógico que marca sua posição naquele fluxo. Em vez de confirmar cada envio individualmente, o servidor informa o progresso acumulado da durabilidade por meio do maior offset confirmado que se tornou persistente até o momento. Como os offsets são ordenados, uma única confirmação valida esse envio e todos os envios anteriores.

Esse é o loop de reconhecimento, e é o que mantém a conexão rápida e confiável:

1. O cliente envia registros e os mantém em um buffer local durante o voo.
2. O servidor persiste os registros de forma durável e retorna periodicamente o maior offset confirmado.
3. Ao receber esse offset, o cliente pode remover com segurança todos os registros armazenados em buffer até esse ponto, pois esses registros já são persistentes.

Quando você usa um SDK Zerobus Ingest, o SDK executa esse ciclo para você. Ele rastreia os offsets, mantém o buffer em trânsito e processa as confirmações em segundo plano, enquanto o produtor continua enviando dados. Você não implementa o loop sozinho. O que você opcionalmente controla é como observa a durabilidade:

• Continue enviando; o SDK processa as confirmações de recebimento à medida que chegam.
• Aguarde um offset somente quando seu aplicativo precisar esperar até que um registro específico seja persistente. Consulte abaixo.
• Registre um callback de confirmação para reagir a confirmações e erros de forma assíncrona, sem bloqueio. Consulte Retornos de chamada de confirmação.

Você só precisaria implementar por conta própria o loop de rastreamento de offsets e em buffer se desenvolvesse um cliente personalizado que não utilizasse um SDK.

O buffer em trânsito é limitado por um limite configurável de registros em trânsito. A ingestão é assíncrona até o buffer encher; nesse ponto, as chamadas de ingestão ficam bloqueadas até que as confirmações cheguem e liberem espaço. Ajuste o limite para sua carga de trabalho e observe que os registros armazenados em buffer consomem memória do cliente enquanto estão em trânsito. Para a opção e seu padrão, veja o repositório Zerobus SDK.

Se a conexão for interrompida, os registros que ainda estiverem no buffer em trânsito (aqueles posteriores ao último offset confirmado) não terão sido confirmados como persistentes e, portanto, poderão ser reproduzidos. Veja Padrões de recuperação e retentativas.

O reconhecimento confirma durabilidade, não possibilidade de consulta. Um offset comprometido significa que esses registros permanecem de forma duradoura e não serão perdidos. O Zerobus Ingest materializa registros duráveis na tabela Delta como uma etapa separada logo depois, momento em que os dados se tornam consultáveis em aproximadamente 5 segundos. Para mais informações sobre latência, veja Latência.

Aguardar um registro versus maximizar a taxa de transferência

Você aguarda o offset de um registro quando seu aplicativo precisa bloquear a execução subsequente até que seja confirmado que aquele registro específico é persistente, por exemplo, antes de confirmar o processamento para um sistema upstream. A espera diz respeito à sincronização em nível de aplicação, não sendo um requisito para durabilidade. Um registro se torna persistente por meio do loop de confirmação, independentemente de você aguardar por ele ou não.

O bloqueio tem um custo em termos de taxa de transferência:

• Esperar após cada registro transforma a ingestão em um fluxo de trabalho efetivamente síncrono. Bloquear cada mensagem antes de enviar a próxima impede que o cliente alcance o throughput total do Zerobus Ingest.
• A ingestão de alta taxa de transferência é contínua e assíncrona. O cliente continua enviando registros enquanto chegam confirmações de grupos de registros anteriores, em vez de pausar a cada registro. Aguarde um offset específico apenas nos pontos de verificação em que seu aplicativo realmente precise dessa garantia ou use um retorno de chamada de confirmação para acompanhar o progresso sem bloquear a execução.

Para obter informações sobre os métodos de ingestão, quando aguardar um offset e como funcionam os retornos de chamada de confirmação, consulte Bloqueio de mensagens e confirmação.

Ordenando em uma transmissão

As confirmações e os offsets são específicos de cada transmissão: a ordenação é garantida dentro de uma única transmissão, e não globalmente entre as transmissões. Para entender como funciona a ordenação por fluxo e como projetar sua solução levando isso em conta, consulte Garantias de ordenação.