Um cenário recorrente em sistemas distribuídos que utilizam mensageria assíncrona é o consumo duplicado de mensagens. Isso pode levar a inconsistências de dados e comportamentos inesperados no sistema. Este artigo explora as causas desse problema, comumente associado à garantia de entrega "pelo menos uma vez" (atleast once), e propõe soluções para garantir a idempotência no processamento.

O problema se manifesta quando uma mensagem é enviada e o produtor não recebe confirmação de processamento bem-sucedido. Por garantia de não perda, o sistema de mensagens reenvia a mensagem, resultando em processamento duplicado pelo consumidor. Isso é um comportamento esperado em garantias de entrega "pelo menos uma vez", onde a perda de mensagens é evitada ao custo de possíveis duplicatas.

A garantia de entrega de mensagens em sistemas de mensageria pode ser classificada em três níveis:

• At most once (No máximo uma vez): Permite perda de mensagens, mas garante que cada mensagem seja entregue no máximo uma vez. Adequado para cenários onde a perda ocasional de dados é aceitável.
• At least once (Pelo menos uma vez): Garante que cada mensagem seja entregue pelo menos uma vez, mas permite duplicatas. Essencial para cenários onde a perda de dados é inaceitável.
• Exactly once (Exatamente uma vez): Garante que cada mensagem seja entregue exatamente uma vez, sem perdas ou duplicatas. É o nível mais alto de garantia, mas também o mais complexo de implementar.

A chave para lidar com o consumo duplicado é a implementação de mecanismos de idempotência no lado do consumidor. Idempotência significa que a execução repetida de uma operação produz o mesmo resultado que a execução única. Um exemplo clássico é uma operação de débito:

Imagine um cenário de pagamento onde um consumidor recebe uma mensagem para debitar R$ 100 de uma conta. Se a mensagem for entregue duas vezes, o sistema não deve debitar R$ 200. A operação de débito deve ser idempotente, resultando em apenas um débito de R$ 100, independentemente de quantas vezes a mensagem foi processada.

Para alcançar a idempotência, é necessário um "identificador" único para cada operação de negócio. No exemplo de pagamento, um número de série de transação ou um ID de pedido único pode servir como essa âncora. As abordagens comuns para implementar idempotência incluem:

Abordagens Comuns para Idempotência

Uma abordagem inicial é registrar cada operação concluída em uma tabela de histórico. Ao receber uma mensagem, o consumidor verifica se a operação correspondente a esse identificador único já foi processada. Se sim, a mensagem é ignorada; caso contrário, a operação é executada e registrada.

Exemplo de lógica de idempotência (pseudocódigo):

fun processarMensagem(mensagem) {
    identificadorUnico = obterIdentificadorUnico(mensagem)
    if (!registroExiste(identificadorUnico)) {
        executarOperacaoDeNegocio(mensagem)
        registrarOperacao(identificadorUnico)
    }
}

O desafio aqui é garantir a atomicidade entre a verificação e o registro. Em cenários de alta concorrência, duas requisições podem passar pela verificação registroExiste simultaneamente, ambas concluindo que a operação não foi registrada, levando a um processamento duplicado antes que o registro seja efetivamente criado.

Para mitigar isso, a maioria dos bancos de dados oferece restrições de chave única. Ao tentar inserir um registro com um identificador que já existe, o banco de dados lançará um erro de violação de chave única. Essa exceção pode ser capturada para indicar que a operação já foi processada.

Exemplo com chave única (pseudocódigo):

fun processarMensagemComChaveUnica(mensagem) {
    identificadorUnico = obterIdentificadorUnico(mensagem)
    try {
        executarOperacaoDeNegocio(mensagem)
        inserirRegistroIdempotencia(identificadorUnico) // Usa chave única no DB
    } catch (ViolacaoChaveUnicaException e) {
        // Operação já foi processada, ignorar duplicata
        log("Mensagem duplicada processada: " + identificadorUnico)
    }
}

No entanto, essa abordagem ainda pode ter uma pequena janela de race condition entre a execução da executarOperacaoDeNegocio e a inserirRegistroIdempotencia. Uma solução mais robusta envolve o uso de transações distribuídas ou a combinação de operações em uma única transação de banco de dados, garantindo que a verificação e a operação de negócio sejam atômicas.

Uma Solução Mais Elegante: Tabela de Registro de Consumo

Uma abordagem mais desacoplada e reutilizável é a criação de uma tabela dedicada para registrar o consumo de mensagens. Essa tabela, separada das tabelas de negócio, atua como um guardião contra duplicatas.

A tabela de registro de consumo teria uma chave primária ou um índice único composto pelo identificador único da mensagem ou da operação de negócio. O processo seria:

1. Ao receber uma mensagem, o consumidor tenta inserir um registro na tabela de registro de consumo usando o identificador único.
2. Se a inserção for bem-sucedida, significa que esta é a primeira vez que a mensagem é processada. O consumidor, então, executa a lógica de negócio.
3. Se a inserção falhar devido a uma violação de chave única, a mensagem já foi processada, e o consumidor ignora a requisição.

Para garantir a atomicidade entre a inserção no registro e a execução da lógica de negócio, transações de banco de dados são ideais. Isso garante que ambas as operações sejam confirmadas ou revertidas juntas.

Exemplo com transação e tabela de registro (pseudocódigo):

fun processarMensagemComTabelaRegistro(mensagem) {
    identificadorUnico = obterIdentificadorUnico(mensagem)
    iniciarTransacao()
    try {
        if (inserirRegistroConsumo(identificadorUnico)) { // Tenta inserir e verifica sucesso
            executarOperacaoDeNegocio(mensagem)
            confirmarTransacao()
        } else {
            reverterTransacao() // Se a inserção falhou (duplicata), reverte
        }
    } catch (Exception e) {
        reverterTransacao()
        log("Erro ao processar mensagem: " + identificadorUnico, e)
        throw e // Re-lança para que o MQ possa tentar novamente
    }
}

Esta abordagem centraliza a lógica de idempotência em uma estrutura reutilizável, liberando as tabelas de negócio de terem que implementar essa validação complexa. A garentia de que a operação de negócio e o registro de consumo ocorram atomicamente transforma a garantia "pelo menos uma vez" do sistema de mensagens em um comportamento efetivamente "exatamente uma vez" do ponto de vista do processamento de negócio.