MQTT vs AMQP: Diferenças, Casos de Uso e Desempenho

MQTT vs AMQP aparece sempre que uma equipe que constrói dispositivos conectados também roda serviços de backend em um message broker como o RabbitMQ. Os dois protocolos usam broker, ambos rodam sobre TCP e ambos oferecem confirmações de entrega, mas foram projetados para trabalhos muito diferentes. Este guia compara modelos de broker, roteamento, garantias e footprint de client, e termina com uma regra prática sobre quando cada um deve entrar na sua arquitetura.

De Onde Vem Cada Protocolo

O MQTT foi projetado para telemetria de equipamentos remotos em links pouco confiáveis e de baixa largura de banda. Suas prioridades são um client minúsculo, um formato de pacote pequeno e um modelo simples: clients publicam em topics hierárquicos e assinam usando wildcards. É um padrão OASIS, com as versões 3.1.1 e 5.0 amplamente usadas.

O AMQP (Advanced Message Queuing Protocol) surgiu no setor financeiro, onde a prioridade era mensageria confiável e interoperável entre sistemas de negócio. Ele tem duas linhagens bem diferentes. O AMQP 0-9-1 é o modelo que a maioria dos desenvolvedores conhece pelo RabbitMQ, com exchanges, bindings e filas. O AMQP 1.0 é o padrão OASIS e ISO, um protocolo de transferência peer-to-peer mais genérico, usado por serviços como o Azure Service Bus e suportado por brokers como o Apache ActiveMQ Artemis. Quando alguém diz "AMQP", vale perguntar a qual deles está se referindo.

MQTT vs AMQP em Resumo

Aspecto	MQTT	AMQP 0-9-1 (estilo RabbitMQ)	AMQP 1.0
Modelo central	Topics com publish/subscribe	Exchanges roteiam para filas via bindings	Links entre nós; semântica do broker definida pela implementação
Roteamento	Topics hierárquicos, wildcards `+` e `#`	Exchanges direct, topic, fanout e headers	Endereços e filtros, específicos do broker
Filas	Sem filas explícitas (filas de sessão por client)	Filas explícitas, nomeadas e duráveis	Nós definidos pelo broker
Garantias de entrega	QoS 0, 1, 2	Acks, publisher confirms, transações	Modos de settlement, at-most-once e at-least-once
Distribuição de trabalho	Shared subscriptions (MQTT 5)	Consumidores concorrentes em uma fila	Receptores concorrentes em um nó
Controle de fluxo	Receive maximum (MQTT 5)	Prefetch (basic.qos)	Controle de fluxo por créditos no link
Tamanho do header	Muito pequeno, header fixo mínimo de 2 bytes	Frames e propriedades maiores	Codificação maior e ricamente tipada
Footprint do client	Cabe em microcontroladores	Confortável em servidores e gateways	Confortável em servidores e gateways
Ambiente típico	Dispositivos, gateways, navegadores, apps móveis	Microsserviços de backend, filas de tarefas	Integração corporativa, serviços de mensageria em nuvem

Modelo de Broker e Roteamento

Um broker MQTT roteia puramente por topic. Um publicador envia para plant1/line2/press4/temperature, e todo client cujo filtro de assinatura corresponda recebe uma cópia. Não há configuração de roteamento separada; a hierarquia de topics é a tabela de roteamento. Isso torna o MQTT fácil de adotar e fácil de entender, especialmente quando os topics seguem uma estrutura como ISA-95 ou um Unified Namespace. O artigo sobre o modelo publish/subscribe do MQTT explica o desacoplamento em mais profundidade.

O AMQP 0-9-1 separa para onde as mensagens são enviadas (uma exchange) de onde elas são armazenadas (filas). Bindings conectam as duas com regras. Uma topic exchange se comporta um pouco como os wildcards do MQTT, uma fanout exchange copia para cada fila vinculada e uma direct exchange roteia por uma chave exata. Essa flexibilidade é poderosa para fluxos de backend, como distribuir um evento de pedido para filas de faturamento, expedição e analytics, cada uma com sua própria retenção e seus consumidores. O preço são mais conceitos para aprender e mais configuração para gerenciar.

Garantias de Entrega

O MQTT oferece três níveis de QoS: no máximo uma vez (QoS 0), pelo menos uma vez (QoS 1) e exatamente uma vez entre client e broker (QoS 2). Sessões persistentes permitem que o broker guarde mensagens QoS 1 e 2 para um assinante temporariamente offline. Para relembrar, veja os níveis de QoS do MQTT explicados.

O AMQP oferece confirmações do consumidor, confirmações negativas com reenfileiramento, publisher confirms e, no 0-9-1, transações. As mensagens ficam em uma fila durável até que um consumidor as confirme explicitamente, que é exatamente o que você quer para tarefas como "gerar esta fatura", que precisam ser processadas por exatamente um worker e repetidas em caso de falha.

Na prática, ambos conseguem entregar de forma confiável. A diferença é a ênfase: o MQTT é otimizado para fluxos de estado e eventos para muitos assinantes; o AMQP, para itens de trabalho duráveis tratados por consumidores concorrentes.

Desempenho e Footprint

Nenhum dos protocolos é "mais rápido" em abstrato. O throughput depende muito mais da implementação do broker, das configurações de persistência, do tamanho das mensagens e do modo de confirmação do que do formato na rede.

Onde os protocolos claramente diferem é no footprint. Uma biblioteca client MQTT cabe confortavelmente em um ESP32 ou microcontrolador semelhante, e o overhead de pacote por mensagem é minúsculo, o que importa em links celulares e de satélite. Clients AMQP são mais pesados, os frames carregam mais metadados e o estabelecimento da conexão envolve mais negociação. Em um servidor essa diferença é irrelevante; em um sensor alimentado por bateria, é decisiva.

O MQTT também lida bem com um número muito grande de conexões quase sempre ociosas, que é o formato normal de uma frota de IoT. Brokers AMQP geralmente são ajustados para menos conexões, porém mais movimentadas, vindas de serviços.

Arquiteturas Típicas

A resposta mais comum no mundo real para MQTT vs AMQP é "os dois, em camadas diferentes":

Dispositivos, gateways e dashboards se conectam a um broker MQTT.
Um serviço de backend assina os topics MQTT relevantes, por exemplo plant1/+/+/telemetry.
Esse serviço valida e enriquece os dados e depois publica itens de trabalho em uma fila AMQP para processamento posterior, como faturamento, abertura de chamados ou atualizações no ERP.

Aqui está uma ponte mínima em Python que assina via MQTT e publica em uma fila do RabbitMQ com pika. Ela roda como um processo próprio, então você controla agrupamento, filtragem e tratamento de erros.

import json
import uuid

import paho.mqtt.client as mqtt
import pika

PREFIX = "connectmq/demo/replace-me"

amqp = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = amqp.channel()
channel.queue_declare(queue="telemetry", durable=True)

def on_connect(client, userdata, flags, reason_code, properties):
    print("MQTT connected:", reason_code)
    client.subscribe(f"{PREFIX}/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    try:
        body = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("skipping invalid payload on", msg.topic)
        return
    body["topic"] = msg.topic
    channel.basic_publish(
        exchange="",
        routing_key="telemetry",
        body=json.dumps(body),
        properties=pika.BasicProperties(delivery_mode=2),  # persistente
    )

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"amqp-bridge-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Em produção, conecte-se ao seu broker privado via TLS na porta 8883 com client.tls_set() e client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"), e use o client ID emitido junto com essas credenciais. Como a conexão bloqueante do pika não é thread-safe, mantenha todas as chamadas AMQP dentro da thread do loop de rede do MQTT, como mostrado, ou entregue as mensagens a uma fila consumida por uma thread AMQP dedicada.

Quando Escolher MQTT

Os clients são microcontroladores, gateways, apps móveis ou navegadores.
As conexões são instáveis, tarifadas por uso ou de alta latência.
Muitos consumidores precisam do mesmo fluxo de telemetria ou estado.
Você precisa de detecção de online/offline (keep alive e Last Will) e de últimos valores conhecidos (retained messages).
Você quer um modelo simples que engenheiros de campo e integradores consigam entender só pelos nomes dos topics.

Quando Escolher AMQP

As mensagens são unidades de trabalho que um único consumidor deve processar e confirmar.
Você precisa de regras de roteamento sofisticadas, dead-letter queues e políticas por fila.
Todos os produtores e consumidores são serviços de backend em um data center ou na nuvem.
Você está integrando sistemas corporativos que já falam AMQP 1.0.

Por Que um Broker MQTT Gerenciado Costuma Ser a Opção Mais Simples

No lado voltado aos dispositivos, a simplicidade operacional costuma vencer. Um broker MQTT gerenciado elimina o trabalho de aplicar patches, renovar certificados, escalar o número de conexões e isolar múltiplos tenants, e deixa sua equipe livre para focar no design de topics e nos consumidores. O ConnectMQ suporta MQTT 3.1.1 e 5.0, TLS com certificado Let's Encrypt, shared subscriptions no plano Serverless pago e cotas por plano com proteção contra flood. Ele não inclui uma ponte AMQP, então você mantém a ponte como um serviço próprio, exatamente como mostrado acima. Para comparar opções de hospedagem de forma mais ampla, leia o guia de broker MQTT na nuvem e, para relembrar topics e sessões, veja o tutorial de MQTT. Se você está ponderando filas versus brokers no nível conceitual, broker MQTT vs fila de mensagens se aprofunda no tema.

Comece com o ConnectMQ

Coloque seus dispositivos no ConnectMQ via MQTT e mantenha o AMQP para os fluxos de backend em que ele é melhor. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, pegue as credenciais geradas e aponte seus dispositivos e seu serviço de ponte para ele em minutos.

Perguntas frequentes

O MQTT é melhor que o AMQP para IoT?

Para dispositivos, geralmente sim: clients MQTT são menores, os pacotes são mais leves e o modelo lida bem com muitas conexões intermitentes. O AMQP é mais adequado para filas de trabalho no backend.

O RabbitMQ fala MQTT?

O RabbitMQ oferece um plugin MQTT que mapeia topics MQTT no seu modelo de exchanges. Um broker MQTT dedicado normalmente oferece suporte mais completo aos recursos do MQTT e operação mais simples para grandes frotas de dispositivos.

O MQTT tem filas como o AMQP?

Não explicitamente. O broker mantém uma fila de sessão por client para sessões persistentes, e as shared subscriptions do MQTT 5 permitem que vários consumidores dividam as mensagens de um topic, o que cobre muitos casos de uso semelhantes a filas.

Posso usar MQTT e AMQP juntos?

Sim, e isso é comum. Os dispositivos publicam via MQTT, e um serviço de ponte assina e encaminha mensagens selecionadas para filas AMQP para processamento no backend.