Comunicação assíncrona

A comunicação num fluxo é assíncrona e bidirecional. O cliente envia registos continuamente sem esperar que cada um seja confirmado, e o servidor envia confirmações através da mesma ligação à medida que os registos são armazenados de forma persistente. Este desacoplamento é o que permite a um único cliente manter um alto rendimento: continua a empurrar enquanto os reconhecimentos chegam em segundo plano.

Offsets e o ciclo de confirmação

Cada submissão num fluxo, seja um único registo ou um lote, recebe um deslocamento lógico que marca a sua posição nesse fluxo. Em vez de reconhecer cada submissão individualmente, o servidor reporta o progresso cumulativo de durabilidade através do maior offset comprometido que já tornou durável até agora. Como os offsets estão ordenados, uma confirmação valida esse envio e todos os anteriores.

Este é o ciclo de reconhecimento, e é o que mantém a ligação rápida e fiável:

1. O cliente envia os registos e mantém-nos num buffer local durante o voo.
2. O servidor armazena os registos de forma duradoura e envia periodicamente o offset confirmado mais elevado.
3. Ao receber esse offset, o cliente elimina com segurança todos os registos em buffer até esse offset, porque esses registos são agora persistentes.

Quando usas um SDK de Ingesta Zerobus, o SDK executa este ciclo por ti. Regista deslocamentos, mantém o buffer em voo e processa confirmações em segundo plano enquanto o teu produtor continua a pressionar. Não implementas o loop tu próprio. O que opcionalmente controlas é como observas a durabilidade:

• Continue a enviar; o SDK processa as confirmações de receção à medida que chegam.
• Bloqueie um offset apenas quando a sua candidatura tiver de esperar que um registo específico seja duradouro. Ver abaixo.
• Registar um callback de confirmação para reagir às confirmações e erros de forma assíncrona, sem bloqueio. Ver chamadas de reconhecimento.

Só implementarias o loop de offset-tracking e buffering se construíres um cliente personalizado que não use SDK.

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

Se a ligação for interrompida, os registos ainda no buffer em voo (os que ultrapassam o último deslocamento comprometido) não foram confirmados como duráveis, pelo que podem ser reproduzidos. Veja Padrões de recuperação e repetição.

O reconhecimento confirma a durabilidade, não a possibilidade de consulta. Uma compensação comprometida significa que esses registos são mantidos de forma duradoura e não se perderão. O Zerobus Ingest materializa registos duráveis na tabela Delta como um passo separado pouco depois, momento em que os dados passam a ser consultados em aproximadamente 5 segundos. Para mais informações sobre latência, veja Latência.

Aguardar um registo versus maximizar a taxa de transferência

Aguarda o deslocamento de um registo quando a sua aplicação tem de bloquear a execução adicional até que esse registo específico seja conhecido como durável, por exemplo, antes de reconhecer o trabalho para um sistema a montante. Esperar é sobre sincronização ao nível da aplicação, não um requisito de durabilidade. Um registo torna-se persistente através do ciclo de confirmação, quer haja bloqueio ou não.

O bloqueio tem um custo de throughput:

• Esperar por cada registo transforma a ingestão num fluxo de trabalho efetivamente síncrono. Bloquear cada mensagem antes de enviar a seguinte impede o cliente de atingir o throughput total do Zerobus Ingest.
• A ingestão de alto débito é contínua e assíncrona. O cliente vai enviando registos enquanto chegam confirmações relativas a grupos de registos anteriores, em vez de fazer uma pausa após cada um. Espere por um offset específico apenas nos pontos de verificação em que a sua aplicação realmente precisa dessa garantia, ou use um callback de confirmação para acompanhar o progresso sem bloquear.

Consulte Bloqueio de mensagens e confirmação para obter informações sobre os métodos de ingestão, quando bloquear num offset e como funcionam os callbacks de confirmação.

Encomendar numa transmissão

As confirmações de receção e os offsets são específicos de cada fluxo: a ordem é garantida dentro de um único fluxo, não a nível global entre fluxos. Para saber como funciona a encomenda por stream e como desenhar em torno disso, veja Garantias de Encomenda.