Spring Batch sem broker: a coordenação não desaparece, muda para SQL

Um artigo da InfoQ apresenta uma implementação de particionamento distribuído para Spring Batch que usa o banco relacional compartilhado como plano de coordenação, sem Kafka, RabbitMQ ou JMS.[5] O alvo declarado são clusters pequenos e médios, com aproximadamente 2 a 20 nós como faixa de referência, não como teto universal garantido.[5]

A proposta é pragmática: evitar operar um broker apenas para distribuir trabalho em lote. O cuidado é não confundir menos componentes instalados com menos responsabilidades operacionais.

O que muda para quem desenvolve

A implementação adiciona tabelas para nós e heartbeats, partições e coordenação de jobs, reaproveitando interfaces e metadados do Spring Batch.[5] O nó que inicia uma execução coordena aquele job, sem liderança permanente do cluster.[5] A distribuição ocorre no início e não oferece roubo automático de trabalho entre workers; a movimentação descrita é provocada por falha de nó.[5]

Atualizações SQL condicionadas ao identificador, ao nó atribuído e ao estado corrente impedem certas gravações atrasadas nos metadados.[5] Isso não garante efeitos externos exatamente uma vez.[5] Para quem implementa o passo de trabalho, a fronteira relevante continua sendo a operação que altera o mundo, não apenas a linha que registra sua conclusão.

Como aplicar

Faça um protótipo com uma carga que possa ser repetida com segurança. Defina uma chave de negócio para reconhecer operações já processadas e um procedimento explícito para reconciliar resultados ambíguos. Antes de medir vazão, escreva o comportamento esperado de recuperação.

Teste separadamente a perda de um worker, a pausa prolongada de um processo e a morte do coordenador. Em cada cenário, acompanhe a atribuição da partição, o estado do job e os efeitos de negócio. Considere falha do experimento qualquer duplicação que os metadados não expliquem.

Meça também polling, conexões ocupadas e contenção no banco junto da carga funcional. Compare esse custo com o de usar a mensageria que a plataforma eventualmente já possui. A economia deve incluir o esforço de manter o protocolo de coordenação.

Cuidados e limites

Partições transferíveis podem ser reexecutadas e exigem idempotência; um processo pausado pode voltar após a transferência e concluir trabalho antigo.[5] As não transferíveis falham em vez de serem movidas.[5] A falha do coordenador é tratada por falha e reinício do job, não por retomada transparente de coordenação.[5]

O banco torna-se dependência crítica, e o artigo aponta brokers como opção preferível quando já existem, a escala cresce ou há necessidade de coordenação subsegundo e de suas garantias específicas.[5] A implementação apresentada é de Spring Batch, não um recurso nativo do Quarkus.[5] Remover um componente é uma decisão válida. Fingir que suas responsabilidades sumiram não é.

Fonte

[5] Fonte: InfoQ