Comunicação assíncrona

A comunicação em uma transmissão é 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 sustente um throughput elevado: ele continua enviando enquanto as confirmações chegam em segundo plano.

Deslocamentos e o loop de reconhecimento

A cada envio em uma transmissão, seja um registro único ou um lote, é atribuído um offset lógico que marca sua posição nessa transmissão. Em vez de confirmar cada envio individualmente, o servidor relata o progresso cumulativo de durabilidade por meio do maior offset consolidado que ele tornou durável até o momento. Como os offsets são ordenados, uma confirmação valida esse envio e todos os anteriores.

Este é o loop de confirmação, 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 em trânsito.
2. O servidor persiste os registros de forma durável e envia periodicamente o deslocamento consolidado mais alto.
3. Ao receber esse offset, o cliente limpa com segurança todos os registros em buffer até ele, pois esses registros agora são duráveis.

Ao usar um SDK do Zerobus Ingest, o SDK executa esse loop para você. Ele rastreia offsets, mantém o buffer em trânsito e processa confirmações em segundo plano enquanto seu produtor continua enviando. Você não implementa o loop por conta própria. O que você controla opcionalmente é como observar a durabilidade:

• Continue enviando; o SDK processa as confirmações à medida que chegam.
• Bloqueie em um offset apenas quando sua aplicação precisar aguardar que um registro específico seja durável. Veja abaixo.
• Registre um retorno de chamada de reconhecimento para reagir a confirmações e erros de forma assíncrona, sem bloquear. Veja Retornos de chamada de reconhecimento.

Você só implementaria o loop de acompanhamento de offset e buffer se criasse um cliente personalizado que não utiliza um SDK.

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

Se a conexão for interrompida, os registros que ainda estiverem no buffer em trânsito (aqueles além do último offset consolidado) não tiveram sua durabilidade confirmada, portanto, podem ser reproduzidos. Consulte Padrões de recuperação e repetição.

A confirmação atesta a durabilidade, não a consultabilidade. Um offset consolidado significa que esses registros são persistidos de forma durável e não serão perdidos. O Zerobus Ingest materializa registros duráveis na tabela Delta como o passo separado logo em seguida, momento em que os dados se tornam consultáveis em aproximadamente 5 segundos. Para mais informações sobre latência, consulte Latência.

Aguardar um registro versus maximizar o throughput

Você aguarda o deslocamento de um registro quando sua aplicação precisa bloquear a execução posterior até que esse registro específico seja conhecido como durável, por exemplo, antes de reconhecer o trabalho para um sistema upstream. A espera trata-se de sincronização em nível de aplicação, não de um requisito para durabilidade. Um registro torna-se durável por meio do loop de reconhecimento, independentemente de você bloqueá-lo ou não.

O bloqueio tem um custo de throughput:

• Aguardar após cada registro transforma a ingestão em um fluxo de trabalho efetivamente síncrono. Bloquear em cada mensagem antes de enviar a próxima impede que o cliente atinja o throughput total do Zerobus Ingest.
• A ingestão de throughput elevado é contínua e assíncrona. O cliente continua enviando registros enquanto as confirmações chegam para grupos de registros anteriores, em vez de pausar em cada um. Aguarde em um offset específico apenas nos checkpoints onde sua aplicação realmente precisa dessa garantia, ou use um callback de confirmação para monitorar o progresso sem bloquear.

Para os métodos de ingestão, quando bloquear em um deslocamento e como funcionam os retornos de chamada de reconhecimento, consulte Bloqueio de mensagens e reconhecimento.

Ordenação em uma transmissão

As confirmações e os deslocamentos são por transmissão: a ordenação é garantida dentro de uma única transmissão, não globalmente entre transmissões. Para saber como funciona a ordenação por transmissão e como projetar com base nela, consulte Garantias de ordenação.