MQTT gerenciado na nuvem

Cotas de Conexão de Broker MQTT: Conexões, Taxas de Mensagens e Limites de Payload

Brokers MQTT gerenciados aplicam cotas de conexões, taxas de mensagens, tamanho de payload e assinaturas. Entenda como cada uma funciona, como os brokers sinalizam violações e como construir clients que as respeitem.

Ilustração de cotas de conexão de broker MQTT com medidores de conexões, taxa de mensagens e tamanho de payload em um broker na nuvem
Rode isso no seu próprio broker MQTTTenha um broker MQTT privado e gerenciado no plano Free e comece com exemplos de código prontos.
Teste grátis Exemplos de código Sem cartão de crédito

As cotas de conexão de broker MQTT decidem quantos clients você pode conectar, com que rapidez eles podem publicar e qual o tamanho máximo de cada mensagem. Este guia explica todas as cotas comuns em um broker MQTT gerenciado, como brokers MQTT 3.1.1 e MQTT 5 sinalizam que você atingiu uma delas e como escrever clients que fiquem com folga dentro dos limites do seu plano.

Por Que Brokers MQTT Gerenciados Aplicam Cotas

Um broker MQTT gerenciado é infraestrutura compartilhada, mesmo quando você tem um cluster dedicado. Memória, CPU, banda de rede e descritores de arquivo são finitos, e um único client mal-comportado, como um firmware preso em um loop de publicação ou uma tempestade de reconexões após uma queda de Wi-Fi, pode degradar o serviço para todos os outros nas mesmas máquinas. As cotas transformam esses recursos finitos em limites explícitos e previsíveis.

Em um serviço multi-tenant, as cotas também são a forma como o isolamento funciona na prática. A ConnectMQ, por exemplo, aplica cotas por plano, proteção contra flood e bloqueio de IP após falhas repetidas de login, para que o problema de um tenant continue sendo problema só daquele tenant. Se o modelo é novo para você, nosso explicativo sobre o que um broker MQTT faz cobre o básico de como clients e brokers interagem.

As Cotas Comuns de Broker MQTT

A maioria dos provedores aplica alguma combinação das cotas abaixo. Os nomes variam, mas os conceitos são os mesmos em todo lugar.

Cota O que conta Sintoma típico ao exceder
Conexões simultâneas Sessões de clients abertas no mesmo instante Novo CONNECT é recusado
Taxa de conexões Novas conexões por segundo ou minuto Reconexões falham durante tempestades
Taxa de mensagens Publicações por segundo por client ou conta O client sofre throttling ou é desconectado
Tamanho máximo de payload Bytes em um único PUBLISH Publicação rejeitada ou conexão fechada
Assinaturas por client Filtros de topic que um client pode manter O SUBACK retorna um código de falha
Profundidade de topic Número de níveis separados por / Publicação ou assinatura rejeitada
QoS mais alto 0, 1 ou 2 Assinatura concedida com QoS menor
Expiração de sessão Por quanto tempo o broker mantém uma sessão offline Mensagens enfileiradas perdidas após a expiração

Limites reais de planos como exemplo

Veja como a ConnectMQ define seus limites por plano:

  • Serverless (Free): até 25 conexões, QoS até 1, mensagens de até 256 KB.
  • Serverless (Paid): até 1.000 conexões, QoS 2, mensagens de até 1 MB, shared subscriptions.
  • Dedicated, BYOC e Self Managed Enterprise: implantações isoladas dimensionadas para a sua carga.
  • Servidor MQTT público (broker.connectmq.com), apenas para testes e protótipos: 64 KB por mensagem, 10 mensagens por segundo por client, 10 assinaturas por client, 8 níveis de topic, QoS de 0 a 2 e expiração de sessão de até 30 minutos.

Como os Brokers Sinalizam que Você Atingiu uma Cota

É aqui que a versão do protocolo faz muita diferença.

MQTT 3.1.1: adivinhando a partir das desconexões

O MQTT 3.1.1 tem apenas um punhado de códigos de retorno no CONNACK e nenhuma forma de o broker explicar uma desconexão. Quando um client 3.1.1 excede um limite, o broker normalmente apenas fecha a conexão TCP. O client vê um genérico "connection lost" e reconecta, muitas vezes batendo de novo no mesmo limite. Diagnosticar problemas de cota no 3.1.1 significa correlacionar logs do client com o que o console do provedor mostrar.

MQTT 5: reason codes explícitos

O MQTT 5 adicionou reason codes a CONNACK, PUBACK, SUBACK e DISCONNECT, o que torna os problemas de cota visíveis para o client. Os que você mais vai encontrar estão definidos na especificação OASIS MQTT 5.0:

Código Nome Significado na prática
0x87 Not authorized Credenciais ou client ID não permitem esta ação
0x8E Session taken over Outro client conectou com o mesmo client ID
0x95 Packet too large O payload excede o tamanho máximo de pacote
0x96 Message rate too high Taxa de publicação excedida
0x97 Quota exceeded Uma cota da implementação ou do plano foi atingida
0x9F Connection rate exceeded Tentativas de conexão demais

A ConnectMQ suporta os reason codes do MQTT 5, incluindo 0x97 quota exceeded, para que um client com MQTT 5 registre uma causa precisa em vez de uma desconexão vaga. Só isso já é um forte motivo para usar MQTT 5 em projetos novos; veja recursos do MQTT 5 para o restante.

Brokers MQTT 5 também podem anunciar limites logo de início em propriedades do CONNACK, como Maximum Packet Size, Receive Maximum, Topic Alias Maximum e Maximum QoS. Um client bem escrito as lê e se adapta.

Como Projetar Clients que Ficam Dentro das Cotas

A melhor estratégia de cotas é um client que nunca chega perto do limite. Estas práticas evitam a maioria dos incidentes de cota.

Leia os limites do broker no momento da conexão

O exemplo em Python abaixo conecta com paho-mqtt 2.x sobre TLS, imprime os limites que o broker anuncia e registra os reason codes na desconexão.

import paho.mqtt.client as mqtt

LIMIT_PROPS = ("MaximumPacketSize", "ReceiveMaximum",
               "TopicAliasMaximum", "MaximumQoS", "SharedSubscriptionAvailable")

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect refused:", reason_code)
        return
    print("connected")
    for name in LIMIT_PROPS:
        value = getattr(properties, name, None)
        if value is not None:
            print(f"  broker limit {name} = {value}")

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("disconnected:", reason_code)
    if reason_code == "Quota exceeded":
        print("plan quota hit; back off and alert an operator")

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()
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Se quiser experimentar antes sem conta, aponte o mesmo script para o servidor MQTT público (gratuito) na porta 1883, com um client ID único e sem credenciais.

Limite a taxa de publicação no client

Nunca dependa do broker para fazer throttling por você. Um pequeno token bucket mantém as rajadas sob controle, o que importa principalmente quando um dispositivo reconecta e tenta descarregar um backlog.

const mqtt = require("mqtt");

const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  clientId: "YOUR_CLIENT_ID",
  username: "YOUR_USERNAME",
  password: "YOUR_PASSWORD",
  protocolVersion: 5,
  reconnectPeriod: 5000,
});

// Token bucket: no máximo RATE mensagens por segundo, rajada de até BURST.
const RATE = 5;
const BURST = 10;
let tokens = BURST;
setInterval(() => { tokens = Math.min(BURST, tokens + RATE); }, 1000);

const queue = [];
function enqueue(topic, payload) { queue.push({ topic, payload }); }

setInterval(() => {
  while (tokens >= 1 && queue.length > 0 && client.connected) {
    const { topic, payload } = queue.shift();
    client.publish(topic, payload, { qos: 1 });
    tokens -= 1;
  }
}, 100);

client.on("connect", () => console.log("connected"));
client.on("disconnect", (packet) => console.log("broker disconnect, reason", packet.reasonCode));

// Simula o envio de um backlog após uma queda.
for (let i = 0; i < 50; i++) enqueue("factory/line1/temp", JSON.stringify({ i, c: 20 + Math.random() }));

Use backoff com jitter na reconexão

Quando um site, como uma mineradora no Pará ou uma fazenda com link rural instável, perde conectividade, centenas de dispositivos podem reconectar no mesmo segundo. Sem backoff randomizado, eles batem juntos na cota de taxa de conexões, falham juntos e tentam de novo juntos. Adicione jitter aleatório a cada atraso de reconexão e limite o atraso máximo a um ou dois minutos.

Mantenha os client IDs únicos e estáveis

Em brokers MQTT gerenciados que vinculam client IDs às credenciais emitidas, como a ConnectMQ, duplicatas são uma armadilha comum. Se você copiar um conjunto de credenciais para dois dispositivos, cada conexão derruba a outra, o que o MQTT 5 reporta como 0x8E session taken over. O resultado parece uma conexão instável e consome rapidamente os limites de taxa de conexões. Emita um conjunto de credenciais por dispositivo ou serviço.

Agrupe leituras pequenas

Dez valores de sensor em uma mensagem JSON custam uma publicação em vez de dez. O agrupamento mantém as taxas de mensagens baixas e geralmente reduz a banda, desde que o lote fique bem abaixo do limite de payload do seu plano.

Use menos assinaturas, e mais amplas

Um único curinga como site1/+/telemetry é mais barato de gerenciar do que dezenas de assinaturas exatas e mantém você longe dos tetos de assinaturas por client.

Checklist de Preparação para Cotas

Antes do rollout, percorra esta lista para cada tipo de client:

  1. Conte as conexões simultâneas, incluindo dashboards, scripts e integrações.
  2. Calcule o pico de publicações por segundo por client, não apenas a média.
  3. Meça o maior payload, incluindo envios de backlog e dumps de erro.
  4. Confirme o nível de QoS de que cada topic precisa e se o plano o suporta.
  5. Verifique se cada dispositivo tem o seu próprio client ID e credenciais.
  6. Implemente backoff exponencial com jitter para reconexões.
  7. Registre os reason codes do MQTT 5 e envie-os para um lugar onde você possa pesquisar.
  8. Deixe folga: planeje para cerca do dobro da carga esperada, para que o crescimento não surpreenda você.

Para a matemática de dimensionamento por trás dos pontos 2 e 3, leia como estimar mensagens MQTT por segundo. Se você está comparando opções de entrada, nosso guia sobre broker MQTT com plano gratuito mostra como as cotas diferem entre planos grátis, e o guia principal de broker MQTT na nuvem cobre as escolhas de hospedagem de forma mais ampla.

Solução de Problemas de Cota

  • Conexões caem a cada poucos segundos: verifique client IDs duplicados antes de qualquer outra coisa.
  • Mensagens grandes desaparecem: compare o tamanho do payload com o limite do plano e com a propriedade Maximum Packet Size do broker.
  • Assinaturas silenciosamente não recebem nada: inspecione os reason codes do SUBACK; um código de falha significa que o filtro não foi aceito.
  • Tudo falha após uma queda geral do site: sua lógica de reconexão não tem jitter e você está acionando a proteção de taxa de conexões.
  • Desconexões sem explicação no MQTT 3.1.1: mude temporariamente o client para MQTT 5 para obter um reason code.

Comece com um Plano MQTT Gerenciado

A ConnectMQ publica os limites dos seus planos com clareza e reporta problemas de cota com reason codes do MQTT 5, para que você projete em torno deles desde o primeiro dia. Comece no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, e depois suba para Serverless pago, Dedicated ou BYOC conforme a frota cresce. Se preferir que outra pessoa opere toda a infraestrutura, um broker MQTT gerenciado cuida de patches, TLS e capacidade para você.

Perguntas frequentes

O que significa o reason code MQTT 0x97?

0x97 é "Quota exceeded" no MQTT 5. O broker está dizendo ao client que um limite da implementação ou do plano foi atingido, então o client deve aplicar backoff em vez de tentar de novo imediatamente.

Dashboards e scripts contam para as cotas de conexão?

Sim. Todo client MQTT com uma sessão aberta conta como uma conexão, seja um sensor, um flow do Node-RED ou uma aba de navegador.

Como sei o tamanho máximo de mensagem que meu broker aceita?

Consulte a documentação do plano e, no MQTT 5, leia a propriedade Maximum Packet Size no CONNACK. O plano Serverless gratuito da ConnectMQ permite 256 KB, e o plano Serverless pago permite 1 MB.

Por que meu dispositivo fica reconectando em loop?

A causa mais comum são dois clients compartilhando um client ID, o que faz o broker desconectar a sessão mais antiga a cada vez. Dê a cada dispositivo as suas próprias credenciais e client ID.

Artigos relacionados

Broker MQTT BYOC: Bring Your Own Cloud Explicado

Um broker MQTT BYOC roda na sua conta de nuvem, mas é operado por um provedor. Entenda como o modelo funciona, a divisão de responsabilidades e como preparar a sua conta para ele.

9 min de leitura

Alternativa ao Google Cloud IoT Core: Opções e Migração Após o Encerramento

O Google desativou o Cloud IoT Core em agosto de 2023. Este guia compara as alternativas realistas, mapeia os conceitos do IoT Core para MQTT puro e mostra como mover dispositivos para um broker MQTT gerenciado mantendo os dados fluindo para o Google Cloud.

9 min de leitura

Mensagens MQTT por Segundo: Como Estimar e Medir a Vazão

O planejamento de vazão em MQTT se resume a algumas fórmulas e a uma medição honesta. Aprenda a estimar mensagens de entrada e saída por segundo, considerar os picos e associar o resultado a um plano de broker.

8 min de leitura

Todos os artigos →

Seu broker MQTT privado está a poucos cliques de distância

Crie uma conta, receba as credenciais do seu broker e conecte seu primeiro dispositivo — sem servidores para instalar, atualizar ou escalar.