MQTT vs Kafka: Mensageria de Dispositivos vs Event Streaming

MQTT vs Kafka é uma das perguntas de arquitetura mais comuns em IoT, e a resposta honesta é que eles resolvem metades diferentes do problema. O MQTT tira os dados de milhares de dispositivos pequenos e conectados de forma intermitente; o Kafka armazena, reproduz e processa fluxos de eventos de alto volume dentro da sua plataforma de dados. Este guia compara os dois, explica onde cada um deixa de funcionar bem e mostra um padrão funcional para mover dados de um broker MQTT para o Kafka com um serviço consumidor que você controla.

Duas Ferramentas para Dois Trabalhos

O MQTT é um protocolo publish/subscribe leve. Os dispositivos abrem uma única conexão TCP com um broker, publicam em topics hierárquicos e assinam os topics de que precisam. O broker roteia as mensagens em tempo real, guarda o último valor retido por topic, armazena em buffer mensagens QoS 1 e 2 para sessões persistentes desconectadas e publica um Last Will quando um dispositivo cai. Ele foi projetado para clients com recursos limitados e redes pouco confiáveis. Se você está começando, o que um broker MQTT faz é um bom ponto de partida.

O Apache Kafka é um commit log distribuído e somente de acréscimo. Produtores gravam registros em topics particionados, o Kafka os armazena de forma durável por um período de retenção configurável e grupos de consumidores leem no próprio ritmo, podendo voltar atrás para reprocessar o histórico. Ele foi projetado para serviços de backend em redes confiáveis que movem grandes volumes de eventos entre sistemas, com ferramentas do ecossistema para stream processing e conectores para bancos de dados e data lakes.

A confusão vem do vocabulário em comum. Os dois têm "topics", os dois têm produtores e consumidores, e ambos são chamados de sistemas de mensageria. Mas um topic MQTT é um endereço de roteamento que pode ser criado na hora, com milhares de variações em seus níveis, enquanto um topic Kafka é um log durável e particionado que você provisiona deliberadamente.

MQTT vs Kafka em Resumo

Por Que os Dispositivos Não Devem Falar Diretamente com o Kafka

É tecnicamente possível rodar um produtor Kafka em um gateway, mas raramente isso termina bem para frotas de dispositivos:

1. Peso do client. Clients Kafka precisam de muito mais memória e CPU do que um microcontrolador tem, e pressupõem conexões estáveis com vários brokers.
2. Modelo de conexão. O Kafka foi feito para um número modesto de produtores movimentados, não para dezenas de milhares de dispositivos enviando cada um uma leitura a cada poucos segundos por links instáveis.
3. Nenhuma semântica de dispositivo. Não há Last Will, nem detecção de offline baseada em keep alive, nem último valor conhecido retido por dispositivo.
4. Comandos para dispositivos. Consumidores Kafka fazem pull; não há forma natural de enviar um comando para um dispositivo específico atrás de NAT.
5. Superfície de segurança. Expor listeners do Kafka à internet para dispositivos significa gerenciar credenciais e ACLs por dispositivo em uma infraestrutura projetada para ficar dentro de uma rede privada.

Por Que o MQTT Sozinho Não É uma Plataforma de Dados

O MQTT tem as lacunas opostas. Um broker roteia mensagens; ele não guarda histórico. Se o seu job de analytics ficar fora do ar por uma hora, as leituras que ele perdeu se foram, a menos que uma sessão persistente as tenha guardado, e filas de sessão não são um armazenamento de longo prazo. Você não consegue reproduzir os dados da semana passada através de um novo algoritmo, nem fazer joins de streams ou calcular janelas dentro do broker. Esse é o trabalho em que o Kafka e seu ecossistema de stream processing são bons.

O Padrão: MQTT na Borda, Kafka no Núcleo

A arquitetura para a qual a maioria das equipes converge é esta:

1. Dispositivos e gateways publicam em um broker MQTT, por exemplo em connectmq/factory1/production/line1/cnc1/telemetry.
2. Um ou mais serviços consumidores assinam os filtros de topic relevantes.
3. Esses serviços validam, enriquecem e atribuem uma chave a cada mensagem e depois a produzem em um topic Kafka como iot.telemetry, normalmente com o ID do dispositivo como chave para manter a ordenação por dispositivo dentro de uma partição.
4. Stream processors, sinks e analytics leem do Kafka.
5. Os comandos fazem o caminho inverso: um serviço consome um topic de comandos no Kafka e publica no topic de comandos MQTT do dispositivo.

O ConnectMQ não inclui uma ponte nativa para Kafka, então a ligação entre os dois é sempre um componente que você executa: seu próprio serviço consumidor, como mostrado abaixo, ou um conector MQTT source pronto para o Kafka Connect, configurado para assinar o seu broker como um client MQTT comum. As duas abordagens tratam o broker como um endpoint MQTT padrão, o que mantém a integração portável.

Construa um Serviço Consumidor de MQTT para Kafka

O serviço Python a seguir assina o ConnectMQ com uma shared subscription, de modo que você pode rodar várias instâncias e deixar o broker dividir a carga entre elas, e produz cada mensagem no Kafka com confluent-kafka. Shared subscriptions exigem MQTT 5 e estão disponíveis no plano Serverless pago e superiores.

pip install "paho-mqtt>=2.0" confluent-kafka

import json
import ssl
import signal
import sys

import paho.mqtt.client as mqtt
from confluent_kafka import Producer

MQTT_HOST = "broker.connectmq.com"
MQTT_FILTER = "$share/kafka-bridge/connectmq/factory1/+/+/+/telemetry"
KAFKA_TOPIC = "iot.telemetry"

producer = Producer({
    "bootstrap.servers": "localhost:9092",
    "enable.idempotence": True,
    "linger.ms": 20,
})

def delivery_report(err, record):
    if err is not None:
        print(f"Kafka delivery failed for key {record.key()}: {err}")

def on_connect(client, userdata, flags, reason_code, properties):
    print("MQTT connected:", reason_code)
    client.subscribe(MQTT_FILTER, qos=1)

def on_message(client, userdata, msg):
    try:
        payload = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("skipping non-JSON payload on", msg.topic)
        return
    levels = msg.topic.split("/")
    device_id = levels[-2]  # ex.: cnc1
    record = {"topic": msg.topic, "device": device_id, "data": payload}
    producer.produce(KAFKA_TOPIC, key=device_id,
                     value=json.dumps(record), callback=delivery_report)
    producer.poll(0)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message

def shutdown(*_):
    client.disconnect()
    producer.flush(10)
    sys.exit(0)

signal.signal(signal.SIGINT, shutdown)
signal.signal(signal.SIGTERM, shutdown)

client.connect(MQTT_HOST, 8883, keepalive=30)
client.loop_forever()

Alguns detalhes de produção importam mais do que o código em si:

• Back-pressure. Se o Kafka estiver indisponível, produce acabará lançando BufferError quando a fila local encher. Decida se vai bloquear, descartar dados QoS 0 ou parar de confirmar mensagens MQTT. O paho confirma mensagens QoS 1 automaticamente depois que o callback retorna, então, para garantias mais fortes, use confirmação manual (client.manual_ack_set(True) e client.ack(msg.mid, msg.qos) depois do callback de entrega do Kafka).
• Chaves. Use o ID do dispositivo como chave no Kafka para que as leituras de cada dispositivo fiquem ordenadas dentro de uma partição.
• Idempotência. O QoS 1 pode entregar duplicatas. Inclua um ID de mensagem ou timestamp no payload para que os consumidores downstream possam deduplicar.
• Escala. Adicione instâncias do serviço; o prefixo $share/kafka-bridge/ faz o broker distribuir as mensagens entre elas. Dê a cada instância seu próprio client ID e credenciais correspondentes, pois duas conexões com o mesmo client ID desconectariam uma à outra. Veja shared subscriptions no MQTT para os detalhes.

Para prototipar sem credenciais, conecte-se à porta 1883 com um client ID único, remova o prefixo $share/ e use um prefixo de topic como connectmq/demo/<random-id>/ no servidor MQTT público (gratuito), pensado para testes. Trate esses dados como públicos.

Escolhendo Entre os Dois, ou Usando Ambos

Use apenas MQTT quando precisar de conectividade de dispositivos em tempo real, dashboards, alertas e comando e controle, e suas necessidades de histórico forem atendidas por um banco de séries temporais alimentado por um assinante. Muitos projetos nunca precisam de Kafka.

Use apenas Kafka quando todos os produtores forem serviços de backend em redes confiáveis e você precisar de fluxos de eventos duráveis e reproduzíveis entre sistemas.

Use os dois quando tiver uma frota de dispositivos e uma plataforma de dados que precise de replay, vários consumidores independentes em velocidades diferentes ou stream processing em escala. Mantenha a fronteira limpa: topics MQTT modelam dispositivos e ativos, topics Kafka modelam fluxos de eventos de negócio.

No lado dos dispositivos, um broker MQTT gerenciado evita que você mesmo tenha de operar dois sistemas distribuídos. Compare as opções no guia de broker MQTT na nuvem, leia MQTT vs AMQP se filas também estiverem na sua lista e revise os fundamentos no tutorial de MQTT.

Conecte Seus Dispositivos ao ConnectMQ

Coloque um broker MQTT gerenciado na frente do seu cluster Kafka e deixe cada sistema fazer o que faz de melhor. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, conecte alguns dispositivos, depois aponte seu serviço consumidor para ele e veja os registros chegarem ao Kafka.

Perguntas frequentes

O Kafka pode substituir um broker MQTT?

Não para frotas de dispositivos. O Kafka não tem clients leves, detecção de offline baseada em keep alive, Last Will nem estado retido, e não foi projetado para quantidades enormes de dispositivos em redes pouco confiáveis.

O MQTT pode substituir o Kafka?

Apenas se você não precisar de histórico durável, replay ou stream processing. Um broker MQTT roteia mensagens em tempo real e guarda apenas o último valor retido por topic.

Como levar dados MQTT para o Kafka?

Rode um componente que assine o broker como client MQTT e produza no Kafka, seja seu próprio serviço consumidor ou um conector MQTT source do Kafka Connect. O ConnectMQ não tem uma ponte nativa para Kafka.

Devo usar QoS 1 ou QoS 0 na ponte de MQTT para Kafka?

Use QoS 1 para dados que você não pode perder e torne o processamento downstream tolerante a duplicatas. QoS 0 é adequado para telemetria de alta frequência em que uma lacuna ocasional é aceitável.