Um sistema pode publicar uma mensagem e continuar trabalhando sem esperar o processamento no destino. Um intermediário separa a publicação, a entrega e a execução, e cada uma dessas etapas tem a própria confirmação.
Publicador, intermediário e consumidor
A mensageria envolve três papéis:
- Publicador: o programa que produz a mensagem.
- Broker: o intermediário, o serviço de mensageria que recebe as mensagens e as distribui conforme a configuração.
- Consumidor: o programa que lê a mensagem e processa os dados.
Em uma fila com vários consumidores, cada entrega vai, em geral, para um só deles, e os consumidores dividem o trabalho. Em um tópico, cada assinatura recebe a própria cópia das mensagens. No Kafka, os consumidores do mesmo grupo dividem as mensagens de um tópico, e grupos diferentes recebem as mesmas mensagens. A fila e o tópico, sozinhos, não definem a persistência, a retenção nem o processamento.
O RabbitMQ, o Apache Kafka, o Amazon SQS e o Azure Service Bus são exemplos de produtos e serviços de mensageria. O MQTT é um protocolo, usado por clientes e brokers compatíveis, com níveis próprios de garantia de entrega.
As confirmações
- Confirmação de publicação: informa que o broker recebeu a mensagem, conforme o produto, e não confirma o processamento pelo consumidor.
- Ack do consumidor: informa que o consumidor aceita a entrega como tratada, com o significado definido pelo protocolo e pela aplicação.
Quando a aplicação confirma antes de atualizar os dados, o ack não comprova a atualização. A falta de confirmação pode provocar uma nova entrega depois de uma desconexão, de um prazo vencido ou de outra condição configurada, e não necessariamente na hora. O Kafka, o SQS e o MQTT usam mecanismos diferentes, e o procedimento de um produto não vale para os outros.
Como a mesma mensagem pode chegar mais de uma vez, o consumidor precisa de uma proteção contra a repetição dos efeitos. Uma transação concluída antes de uma falha na confirmação pode reaparecer em uma nova entrega.
DLQ e acúmulo
A DLQ, sigla de dead-letter queue, é a fila que guarda as mensagens desviadas por uma política, como o excesso de tentativas, a rejeição ou a expiração, quando o produto e a configuração oferecem esse recurso. Nem toda integração tem uma DLQ.
Uma fila que só cresce mostra uma diferença entre a produção e o consumo. Um consumidor parado ou lento, um volume alto e falhas no tratamento são hipóteses, e as taxas de entrada e de saída e a situação das mensagens separam essas hipóteses.
A gravação e a confirmação
No consumo com confirmação manual, gravar o efeito e confirmar depois deixa uma janela: o banco grava, e o consumidor cai antes do ack. A mensagem volta, embora o negócio já tenha sido aplicado. Confirmar antes de gravar cria o risco contrário, porque uma falha depois da confirmação deixa o trabalho sem aplicação e sem nova entrega.
A proteção mais segura grava a identidade da mensagem tratada junto com o efeito, na mesma transação, quando o banco e o desenho da solução permitem. Uma verificação de existência feita separadamente por dois consumidores pode deixar os dois prosseguirem. As garantias de entrega de um protocolo também não tornam única uma alteração feita em outro banco ou em outra API.
Antes de devolver as mensagens da DLQ para processamento, convém conferir o motivo do desvio, os efeitos já aplicados, a correção necessária e a validade atual de cada operação. A devolução de todas as mensagens sem essa análise pode repetir um pedido antigo ou recriar o mesmo ciclo de erro.
No suporte
Diante de uma mensagem que não chegou ao destino, convém acompanhar o identificador da publicação até o processamento e conferir a confirmação, a fila ou a assinatura, o consumidor, as tentativas e a política de desvio. O significado da palavra enviado no log precisa ser conhecido antes de afirmar que o broker recebeu a mensagem.
Para guardar
- Publicação, entrega e processamento são etapas diferentes, com confirmações diferentes.
- Na fila, os consumidores dividem as mensagens, e, no tópico, cada assinatura recebe a sua cópia.
- O ack, a nova entrega e a retenção dependem do produto e da configuração.
- A mesma mensagem pode chegar mais de uma vez, e o consumidor se protege contra efeitos repetidos.
- A DLQ existe quando há um recurso e uma política configurados.
O sistema registra um pedido enviado para a fila, mas o pedido não aparece no destino. O que investigar?
O significado de enviado no log e o recebimento no broker e, em seguida, a fila ou a assinatura, o consumidor, as tentativas e a DLQ, quando configurada. Cada etapa fornece uma evidência diferente.
Uma mensagem foi entregue de novo depois que o consumidor caiu. Isso prova que a primeira tentativa não alterou os dados?
Não. A operação pode ter terminado antes da confirmação do consumo. Os identificadores e a proteção contra repetição são conferidos antes de qualquer nova execução dos efeitos.