Broker MQTT vs fila de mensagens é uma distinção que confunde muitas equipes, porque ambos são "message brokers" que ficam entre produtores e consumidores. A diferença está na semântica de entrega: um broker MQTT copia cada mensagem para todos os assinantes interessados naquele momento, enquanto uma fila de mensagens guarda cada mensagem até que exatamente um consumidor assuma a responsabilidade por ela. Este guia explica os dois modelos, compara-os com filas no estilo RabbitMQ e SQS e mostra quando um broker MQTT na nuvem é o bloco de construção certo.
Dois Modelos de Entrega
Publish/subscribe baseado em topics (MQTT). Um publicador envia uma mensagem a um topic como plant1/line2/press4/temperature. O broker examina todas as assinaturas atuais, encontra aquelas cujos filtros correspondem e entrega uma cópia a cada uma. Se cinco serviços assinam, cinco cópias são enviadas. Se ninguém assina, a mensagem é descartada, a menos que seja retida como o último valor do topic ou enfileirada em uma sessão persistente. O trabalho do broker é rotear, não armazenar. Para um olhar mais profundo sobre o modelo, veja o modelo publish/subscribe do MQTT.
Filas ponto a ponto (RabbitMQ, SQS e similares). Um produtor envia uma mensagem para uma fila. A mensagem espera ali, de forma durável, até que um consumidor a receba. Com vários consumidores na mesma fila, cada mensagem vai para apenas um deles; eles competem pelo trabalho. O consumidor confirma depois de processar e, se cair antes de confirmar, a mensagem volta a ficar visível para outro consumidor. O trabalho da fila é garantir que cada unidade de trabalho seja feita uma vez por alguém.
Resumindo: o MQTT responde "quem precisa saber disso?", e uma fila responde "quem vai fazer este trabalho?".
Broker MQTT vs Fila de Mensagens Comparados
| Aspecto | Broker MQTT | Fila de mensagens (estilo RabbitMQ, SQS) |
|---|---|---|
| Entrega | Cópia para cada assinante correspondente | Cada mensagem para um único consumidor |
| Endereçamento | Topics hierárquicos, wildcards + e # |
Filas nomeadas (mais exchanges e bindings no RabbitMQ) |
| Mensagem criada sem consumidor | Descartada, a menos que retida ou guardada para uma sessão persistente | Armazenada até ser consumida ou expirar |
| Armazenamento | Último valor retido por topic, filas de sessão por client | Filas duráveis, muitas vezes com retenção longa |
| Confirmação | QoS 1 e 2 entre client e broker | Ack do consumidor após o processamento, reentrega em caso de falha |
| Distribuição de trabalho | Shared subscriptions no MQTT 5 | Consumidores concorrentes nativos |
| Tratamento de dead-letter | Não faz parte do MQTT | Recurso comum (dead-letter queues e exchanges) |
| Ordenação | Por topic, por sessão de client | Por fila, com ressalvas quando há reentrega |
| Modo de entrega | Push para clients conectados | Push (RabbitMQ) ou pull/long poll (SQS) |
| Footprint do client | Minúsculo, roda em microcontroladores | SDKs de classe servidor |
| Presença e estado | Keep alive, Last Will, retained messages | Não se aplica |
| Uso típico | Telemetria de dispositivos, comandos, estado ao vivo, dashboards | Jobs em segundo plano, processamento de pedidos, microsserviços desacoplados |
Onde os Modelos se Sobrepõem
A linha divisória não é perfeitamente nítida, e isso é parte da confusão.
O MQTT tem dois recursos parecidos com filas. Uma sessão persistente faz o broker enfileirar mensagens QoS 1 e 2 para um client enquanto ele está offline; com o MQTT 5 você limita isso com um session expiry interval. Shared subscriptions ($share/group/filter) permitem que vários clients de um grupo dividam as mensagens de um topic, de modo que cada mensagem chegue a um membro do grupo, o que é exatamente o comportamento de consumidores concorrentes. Leia shared subscriptions no MQTT e sessão persistente no MQTT para os detalhes.
Sistemas de filas, por sua vez, oferecem pub/sub. As exchanges fanout e topic do RabbitMQ copiam uma mensagem para várias filas, e serviços em nuvem combinam um topic de notificação com várias filas para fazer fan-out. Mas cada assinante ainda precisa de sua própria fila declarada antecipadamente.
Então a verdadeira pergunta não é quais recursos existem, e sim qual modelo é nativo. O MQTT é fan-out nativo com assinaturas leves e dinâmicas; filas são distribuição de trabalho durável nativa.
Veja a Diferença em Dois Minutos
Você pode observar o fan-out no servidor MQTT público gratuito com os clients do mosquitto. Use um prefixo único para não ver as mensagens de outras pessoas e lembre-se de que ele serve apenas para testes, nunca para dados de produção.
PREFIX="connectmq/demo/$(openssl rand -hex 4)"
# Fan-out: rode isto em dois terminais, cada um com um client ID diferente
mosquitto_sub -h broker.connectmq.com -V mqttv5 -i fan-$RANDOM \
-t "$PREFIX/orders/new" -v
# Publique cinco mensagens, devagar o suficiente para o limite de taxa por client
for i in 1 2 3 4 5; do
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i pub-$RANDOM -q 1 \
-t "$PREFIX/orders/new" -m "order $i"
sleep 0.5
done
Os dois assinantes imprimem os cinco pedidos. Para o comportamento de fila, você precisa de um plano de broker com shared subscriptions, como um broker Serverless pago no ConnectMQ. Inicie dois workers com suas próprias credenciais (cada worker precisa de seu próprio client ID e das credenciais correspondentes do portal) e publique de novo:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t '$share/workers/orders/new' -v
Os dois workers com shared subscription dividem as mensagens, então cada um imprime apenas uma parte. Depois, pare os dois workers, publique de novo e inicie-os outra vez: os pedidos publicados enquanto estavam offline se perderam. Apenas uma sessão persistente os teria guardado, e mesmo assim só para aquele client e só dentro do session expiry interval. Essa é a lacuna que uma fila de verdade preenche.
Quando Usar um Broker MQTT
Um broker MQTT é o bloco de construção certo quando:
- Os produtores são dispositivos. Sensores, gateways de PLC, veículos, apps móveis e navegadores precisam de clients pequenos e de um tratamento tolerante de conexões.
- Muitos consumidores precisam dos mesmos dados. Uma leitura vai ao mesmo tempo para um dashboard, um gravador de historiador e um serviço de alertas, e adicionar um quarto consumidor não exige nenhuma mudança no produtor.
- O estado atual importa mais que o histórico. Retained messages entregam a cada novo assinante o último valor conhecido instantaneamente.
- Você precisa de presença. Keep alive e Last Will avisam quando um dispositivo fica offline.
- Você precisa enviar comandos a dispositivos específicos atrás de NAT ou em links celulares.
Se brokers em geral são novidade para você, o que um broker MQTT faz cobre o básico, e o tutorial de MQTT percorre topics, QoS e sessões.
Quando Usar uma Fila de Mensagens
Uma fila é o bloco de construção certo quando:
- Cada mensagem é um job que precisa ser processado exatamente uma vez por um worker, como gerar uma fatura ou redimensionar uma imagem.
- O trabalho precisa sobreviver a longas indisponibilidades dos consumidores, por horas ou dias.
- Você precisa de novas tentativas e tratamento de dead-letter para mensagens que falham repetidamente.
- Produtores e consumidores são serviços de backend em redes confiáveis.
Usando os Dois Juntos
A maioria das plataformas de IoT acaba usando os dois. Os dispositivos publicam em um broker MQTT. Um serviço consumidor assina, normalmente por meio de uma shared subscription para poder escalar horizontalmente, filtra o fluxo até os eventos que precisam de processamento, por exemplo "alarme disparado" em uma usina ou "lote concluído" em um frigorífico, e os enfileira como jobs no RabbitMQ ou no SQS. A telemetria ao vivo continua fluindo para os dashboards via MQTT, enquanto os fluxos de negócio duráveis rodam a partir da fila. O artigo MQTT vs AMQP inclui uma ponte funcional em Python.
Ao escolher o lado MQTT, decida se vai operá-lo você mesmo ou usar um broker MQTT na nuvem. O ConnectMQ é um broker MQTT gerenciado com MQTT 3.1.1 e 5.0, TLS, retained messages, session expiry e, no plano Serverless pago, shared subscriptions, além de isolamento multi-tenant e cotas por plano. Ele é um broker, não uma fila: não tem ponte nativa para filas, então seu serviço consumidor faz a transferência, o que mantém a fronteira explícita.
Comece com o ConnectMQ
Use um broker MQTT para aquilo que ele faz de melhor, fan-out, estado ao vivo e conectividade de dispositivos, e combine-o com uma fila quando precisar de jobs duráveis. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e experimente a demonstração de fan-out e de shared subscription acima no seu próprio broker privado.
Perguntas frequentes
Um broker MQTT é uma fila de mensagens?
Não no sentido clássico. Um broker MQTT roteia cópias de cada mensagem para todos os assinantes atuais, enquanto uma fila armazena cada mensagem até que um consumidor a processe. O MQTT tem recursos parecidos com filas, mas é pub/sub em sua essência.
O MQTT pode garantir que uma mensagem seja processada uma única vez?
O QoS 2 garante entrega exatamente uma vez entre um client e o broker, não o processamento de ponta a ponta. Para processar jobs uma única vez, use consumidores idempotentes ou entregue o trabalho a uma fila de mensagens.
O que acontece com mensagens MQTT quando ninguém está inscrito?
Elas são descartadas, a menos que a mensagem seja retida, caso em que o broker a guarda como o último valor do topic, ou que exista uma sessão persistente para um assinante offline.
Devo usar RabbitMQ ou um broker MQTT para dispositivos IoT?
Conecte os dispositivos a um broker MQTT, que foi feito para muitos clients leves e intermitentes. Use o RabbitMQ por trás dele para filas de trabalho no backend, se seus fluxos precisarem delas.
