Comparação de Brokers MQTT Open Source: Mosquitto, EMQX, VerneMQ e NanoMQ

Esta comparação de brokers MQTT open source analisa quatro projetos amplamente usados, Eclipse Mosquitto, EMQX, VerneMQ e NanoMQ, sob a ótica de quem precisa operá-los. Você vai entender em que cada broker se destaca, quanto esforço operacional ele cobra e como subir cada um localmente em poucos minutos. Ao final, você deve saber qual deles se encaixa no seu projeto, ou se entregar a operação a um broker MQTT gerenciado é a troca mais vantajosa.

Por Que Comparar Brokers MQTT Open Source?

Toda implantação MQTT precisa de um broker: o servidor que aceita conexões, autentica clientes e roteia cada mensagem publicada para todos os assinantes correspondentes. Se quiser relembrar esse papel, leia o que um broker MQTT faz. O protocolo é padronizado, então qualquer cliente compatível conversa com qualquer broker compatível. O que muda entre os brokers é tudo o que está ao redor do protocolo: como escalam, como armazenam sessões, como você configura a autenticação, como se comportam durante upgrades e quanto do seu tempo exigem.

Os quatro projetos abaixo são maduros, são usados ativamente em produção em algum lugar e implementam MQTT 3.1.1 e MQTT 5.0. Nenhum deles é "o melhor" em termos abstratos. A escolha certa depende do número de conexões, da necessidade de clustering, do que a sua equipe já conhece e dos termos de licença que a sua organização aceita.

Os Quatro Brokers em Resumo

Eclipse Mosquitto

O Mosquitto é o ponto de referência pelo qual a maioria das pessoas começa. Ele é escrito em C, mantido pela Eclipse Foundation e pequeno o bastante para rodar em um Raspberry Pi ou dentro de um contêiner com poucos megabytes de memória. A configuração é um único arquivo de texto, a autenticação é feita por um arquivo de senhas ou pelo plugin de segurança dinâmica, e o bridging permite que uma instância do Mosquitto encaminhe topics para outro broker.

A principal limitação arquitetural é que o Mosquitto roda como um único nó. Não há clustering nativo, então alta disponibilidade significa um arranjo externo de failover e um plano para o estado das sessões. Para um único site (por exemplo, uma planta em Joinville), um laboratório, um gateway de borda ou alguns milhares de dispositivos em um servidor bem dimensionado, isso muitas vezes é perfeitamente adequado.

EMQX

O EMQX é construído sobre Erlang/OTP e projetado em torno de clustering desde o início. Vários nós formam um único broker lógico, o que permite distribuir números muito grandes de conexões entre máquinas. Ele vem com um dashboard web, um sistema rico de autenticação e autorização, e um motor de regras e integrações de dados integrados em seu conjunto de recursos. Há um operador Kubernetes disponível para implantações em cluster.

O licenciamento merece atenção: o EMQX mudou seu modelo de licença ao longo das versões, e os termos das versões mais recentes diferem dos de releases open source mais antigos. Leia a licença atual no site do EMQX e confirme que ela atende ao seu uso antes de padronizar nele.

VerneMQ

O VerneMQ também é construído sobre Erlang e oferece clustering sem nó mestre, hooks de plugins para autenticação e autorização, e recursos como mountpoints para separar espaços de topics. O código-fonte é publicado sob a licença Apache 2.0. Seus pacotes pré-compilados oficiais e imagens de contêiner têm termos próprios (a imagem Docker pede que você aceite um EULA por meio de uma variável de ambiente), então verifique qual distribuição você está usando. Como em qualquer projeto, observe a atividade recente de releases e os canais de suporte da comunidade antes de se comprometer.

NanoMQ

O NanoMQ, da equipe da EMQ, é um broker leve escrito em C sobre a biblioteca de mensagens NNG. Ele mira dispositivos de borda e gateways: footprint pequeno, desempenho multi-thread em hardware modesto e bridging para um broker upstream. É uma escolha natural quando você quer um broker local em um PC industrial ou gateway que encaminha topics selecionados para um broker central ou na nuvem.

Tabela Comparativa de Recursos e Operação

A tabela resume a arquitetura e as características operacionais típicas. Sempre confirme os detalhes na documentação atual de cada projeto, já que recursos mudam entre versões.

Duas observações se destacam. Primeiro, brokers de nó único são mais simples de operar, mas obrigam você a resolver a disponibilidade por conta própria. Segundo, brokers em cluster resolvem disponibilidade e escala, mas acrescentam peças móveis: descoberta de nós, partições de rede, upgrades graduais e monitoramento ciente do cluster.

Teste Cada Broker Localmente com Docker

A forma mais rápida de formar uma opinião é rodar cada broker e conectar um cliente. Os comandos abaixo são apenas para testes locais, com acesso anônimo habilitado. Não exponha essas configurações à internet.

# Mosquitto 2.x needs an explicit listener to accept non-localhost connections
mkdir -p mosquitto/config
cat > mosquitto/config/mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
EOF
docker run -d --name mosquitto -p 1883:1883 \
  -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto:2

# EMQX (dashboard on http://localhost:18083)
docker run -d --name emqx -p 1884:1883 -p 18083:18083 emqx/emqx:latest

# VerneMQ (accept the image EULA and allow anonymous for a local test)
docker run -d --name vernemq -p 1885:1883 \
  -e DOCKER_VERNEMQ_ACCEPT_EULA=yes \
  -e DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on vernemq/vernemq

# NanoMQ
docker run -d --name nanomq -p 1886:1883 emqx/nanomq:latest

Depois, rode o mesmo teste de publish e subscribe em cada porta:

for port in 1883 1884 1885 1886; do
  mosquitto_sub -h localhost -p $port -i sub-$port -t 'test/compare' -C 1 -W 5 &
  sleep 1
  mosquitto_pub -h localhost -p $port -i pub-$port -t 'test/compare' -m "hello from $port"
  wait
done

Cada assinante deve imprimir uma mensagem e encerrar. Quando isso funcionar, começa a parte interessante: habilite autenticação, adicione TLS, reinicie o contêiner enquanto um cliente mantém uma sessão persistente e veja o que sobrevive. Esse exercício diz mais sobre a operação do dia a dia do que qualquer lista de recursos.

O Que a Lista de Recursos Não Mostra

TLS e Certificados

Todo broker suporta TLS, mas alguém precisa obter certificados, renová-los antes que expirem e recarregar o broker sem derrubar todos os dispositivos. Automatizar isso com ferramentas ACME é bem viável, e também é uma fonte clássica de indisponibilidade quando um job de renovação falha silenciosamente.

Upgrades e Conexões de Longa Duração

Conexões MQTT duram dias ou meses. Reiniciar um broker de nó único desconecta todos os clientes de uma vez, e todos eles reconectam no mesmo instante. Brokers em cluster conseguem fazer upgrades nó a nó, mas os clientes do nó que está reiniciando ainda precisam reconectar. Planeje um backoff de reconexão aleatório no lado do dispositivo, qualquer que seja o broker escolhido.

Monitoramento e Capacidade

Você precisa acompanhar número de conexões, taxas de mensagens, mensagens descartadas, memória e descritores de arquivo. O Mosquitto publica estatísticas em topics $SYS/; os brokers em cluster expõem APIs HTTP e endpoints de métricas. De qualquer forma, você mesmo constrói os dashboards e as regras de alerta. Nosso guia de monitoramento de broker MQTT lista as métricas que valem a pena acompanhar.

Operações de Segurança

Portas MQTT expostas atraem scanners rapidamente. Hardening significa desabilitar o acesso anônimo, limitar a taxa de logins com falha, manter o broker e a imagem base atualizados e revisar a configuração após cada upgrade. O artigo de boas práticas de segurança MQTT cobre o lado do cliente nesse cenário.

Como Escolher Entre Eles

Use estas perguntas como roteiro de decisão:

1. Quantas conexões simultâneas você espera em dois anos? Se um único servidor bem provisionado dá conta com folga, o Mosquitto mantém tudo simples. Se não, considere opções em cluster.
2. Você precisa do broker na borda? Para gateways e PCs industriais, Mosquitto ou NanoMQ são escolhas naturais, geralmente fazendo bridging para um broker central.
3. Alta disponibilidade é um requisito obrigatório? Então rode um broker em cluster ou projete um failover externo para um de nó único, incluindo o que acontece com as sessões persistentes.
4. Quais termos de licença a sua organização aceita? Leia a licença atual da versão e da distribuição exatas que você vai implantar.
5. Quem vai ficar de plantão? Um broker é infraestrutura. Se ninguém na equipe quer assumir patches, certificados e alertas às 3 da manhã, leve isso em conta agora.

Se a pergunta cinco fizer você hesitar, compare o esforço com uma análise de broker MQTT auto-hospedado vs gerenciado antes de decidir.

Quando um Broker MQTT Gerenciado Faz Mais Sentido

Brokers open source são softwares excelentes. O custo de operá-los é, em grande parte, tempo das pessoas: configurar TLS, construir monitoramento, conduzir upgrades, ajustar limites e responder a incidentes. Para muitas equipes de IoT, esse tempo rende mais quando aplicado a dispositivos e aplicações.

Um broker MQTT gerenciado transfere essas tarefas para o provedor. Com o ConnectMQ, você cria um broker no portal e recebe usuário, senha e client ID. Os endpoints ficam prontos em TCP 1883, TLS 8883, WebSocket 8083 e Secure WebSocket 8084 (caminho /mqtt) com certificado Let's Encrypt, e clientes MQTT 3.1.1 e MQTT 5.0 funcionam sem alterações. Como o MQTT é um padrão, o mesmo código cliente que você testou contra Mosquitto ou EMQX se conecta ao ConnectMQ trocando apenas host, porta e credenciais.

O ConnectMQ também adiciona ferramentas que você teria de montar por conta própria: um cliente MQTT no navegador, um explorador de topics ao vivo, um dashboard, uma visão de dispositivos organizada por níveis ISA-95 e regras de alerta por limite com log de alertas. Os planos vão de um nível Serverless gratuito em cluster compartilhado, passando por clusters isolados Dedicated, até BYOC na sua própria conta de nuvem, para que o modelo de hospedagem acompanhe os seus requisitos. O guia de broker MQTT na nuvem explica como esses modelos se comparam.

Um padrão sensato é o híbrido: manter Mosquitto ou NanoMQ na borda para resiliência local e fazer bridging de topics selecionados para um broker MQTT gerenciado usado pelas suas aplicações em nuvem e dashboards.

Teste Contra um Broker Hospedado em Minutos

Antes de escolher, aponte o seu cliente atual para um broker hospedado e compare a experiência com os seus contêineres locais. O servidor MQTT público (gratuito) em broker.connectmq.com não exige conta; use um client ID e um prefixo de topic exclusivos e lembre-se de que topics públicos podem ser lidos por qualquer pessoa, por isso ele serve apenas para testes e protótipos.

mosquitto_sub -h broker.connectmq.com -p 1883 -i cmp-sub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -v &
mosquitto_pub -h broker.connectmq.com -p 1883 -i cmp-pub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -m 'hello from the comparison test'

Para dados de produção, crie um broker privado e conecte via TLS na porta 8883 com as suas próprias credenciais.

Comece com o ConnectMQ

Se você prefere dedicar seu tempo a dispositivos e aplicações em vez de operar brokers, crie um broker Serverless gratuito em app.connectmq.com. Não é preciso cartão de crédito, e você pode migrar para Dedicated ou BYOC depois sem alterar o código dos seus clientes MQTT.

Perguntas frequentes

Qual broker MQTT open source é melhor para iniciantes?

O Mosquitto costuma ser o ponto de partida mais fácil. Ele é instalado em minutos, usa um único arquivo de configuração legível e está documentado em inúmeros tutoriais.

O Mosquitto pode rodar em cluster?

Não nativamente. O Mosquitto roda como um único nó; você pode fazer bridging entre instâncias ou montar um failover externo, mas para um cluster multinó de verdade o caminho é um broker projetado para clustering.

O EMQX ainda é open source?

O licenciamento do EMQX mudou ao longo das versões, então a resposta depende da versão que você implanta. Verifique a licença publicada com o release exato que você pretende usar.

Posso migrar de um broker open source para um broker MQTT gerenciado depois?

Sim. O MQTT é um padrão, então os clientes normalmente só precisam de novo host, porta e credenciais. Revise os recursos específicos do broker dos quais você depende, como motores de regras ou plugins, porque eles não migram automaticamente.