APRENDER. PRATICAR. EVOLUIR.Publicar, encaminhar e concluir
Na integração AMQP 0-9-1, separa aceitação pelo broker, routing e conclusão de negócio. Num exemplo RabbitMQ 4.3, a aplicação publica com mandatory e recebe retorno por falta de destino, seguido de publisher ack. A confirmação não transforma uma mensagem sem routing numa instrução processada. Conserva identificadores e motivo do retorno; verifica exchange, bindings e chave usada. Só depois define repetição controlada e critérios de aceitação. O relatório operacional deve mostrar o estado conhecido em cada fronteira, incluindo resultados pendentes no consumidor, para que o negócio não receba um sucesso que a evidência não sustenta.
Tags, canais e conclusão fora de ordem
Delivery tags pertencem ao canal onde a entrega ocorreu. Ao distribuir trabalho por threads, conserva a associação entre entrega e canal e respeita o modelo da biblioteca. Uma confirmação enviada noutro canal pode produzir unknown delivery tag e fechar esse canal. Atenção também a multiple: confirmar até ao tag 12 pode incluir 10 e 11 ainda pendentes. Num exercício, 12 termina primeiro e 10 continua a escrever. Usa confirmação individual ou acompanha uma fronteira de trabalho efetivamente concluído. O broker não conhece automaticamente o estado transacional do handler nem corrige uma confirmação prematura.
Prefetch e paragem do consumidor
O prefetch limita entregas pendentes dentro do âmbito configurado. Com três consumidores e limite individual de vinte, sem outro teto, podem existir até sessenta entregas por confirmar. Esse valor é capacidade permitida, não prova de atividade útil. Relaciona-o com memória, duração dos handlers e capacidade da dependência. Durante shutdown, cancelar a subscrição impede novas entregas futuras, mas não conclui nem recoloca automaticamente as anteriores. Conta o trabalho em curso e define conclusão ou recuperação controlada antes de fechar o canal. Confirma sempre o comportamento da biblioteca e da versão em uso.
Retries e contadores na versão correta
Uma mensagem inválida pode consumir recursos ao circular rapidamente sem progredir. Em quorum queues RabbitMQ 4.3, basic.nack usado para devolver a mensagem não incrementa delivery-count como basic.reject; não assumes que delivery-limit interrompe esse loop. Define um orçamento de repetição e atraso apropriado e um percurso de retenção para itens não processáveis. Num exercício, a fila útil abranda após uma migração porque a equipa manteve uma suposição antiga sobre contadores. Identifica a semântica efetiva e protege o fluxo antes de mudar rejeições. Rejeitar sem requeue e sem destino adequado pode trocar amplificação por perda.
Dead-lettering e pressão na origem
Dead-lettering é outra transferência que pode falhar. Uma DLX configurada não demonstra, sozinha, retenção segura quando o destino está indisponível. No modo at-least-once das quorum queues, valida os requisitos em conjunto, incluindo estratégia e overflow compatíveis. Enquanto faltam confirmações, a origem retém mensagens e consome recursos; acompanha limites e disponibilidade do destino. Num caso de pressão, mudar para drop-head não é um ajuste neutro: pode eliminar itens ainda não confirmados. A decisão precisa de população, impacto e autorização. Mantém tratamento de duplicados, porque uma transferência com repetição não garante efeitos únicos na aplicação.
Recuperar topologia, identidade e resultados
Uma ligação recuperada não significa que a integração já pode continuar. Confirma canais e topologia necessária antes das subscrições e respeita o que a biblioteca recupera automaticamente. Depois, reconcilia publishes sem confirm e entregas com resultado desconhecido. Preservar um ID de negócio ajuda a reconhecer repetição, mas exige tratamento idempotente e estado persistido na aplicação; o campo não implementa essa lógica sozinho. Num exercício, um publisher repete após perder o confirm. O consumidor deve reconhecer o resultado já aplicado e evitar duplicar o efeito, mantendo evidência e critérios de fecho para o lote.
Um publish mandatory recebe basic.return e depois ack. O ack não faz desaparecer a falha de routing: preserva a operação e verifica a topologia antes de repetir.
Armadilhas comuns
Confirm como conclusão de negócio; tags globais; nack como contador universal; DLX configurado como retenção garantida.
Tópicos relacionados: Operar TLS, certificados e configuração · Gerir filas, confirmações e repetição · Lançar, observar e recuperar middleware
Define o âmbito de cada confirmação e verifica retenção, identidade e estado antes de recuperar.
Referência: Consumer acknowledgements and publisher confirms · DR Middleware 2026.4; HotSpot JDK 25; JDBC 25; PostgreSQL 18; RabbitMQ 4.3; OpenSSL 3.5; explicitly scoped runtime references