Alta Disponibilidade de Broker MQTT: Conceitos, Design de Clientes e Perguntas a Fazer

Alta disponibilidade de um broker MQTT significa manter dispositivos e aplicações se comunicando quando parte do sistema falha, e isso depende tanto dos seus clientes quanto do broker. Este artigo explica os conceitos principais, o que realmente acontece com sessões e mensagens durante um failover, como projetar clientes que se recuperam de forma limpa e quais perguntas fazer a qualquer provedor, incluindo a ConnectMQ, antes de confiar nele.

O Que Alta Disponibilidade Significa para MQTT

Em termos gerais de infraestrutura, alta disponibilidade significa projetar um sistema de modo que a falha de um componente não derrube o serviço inteiro por muito tempo. Para um broker MQTT, isso se divide em três perguntas distintas:

1. Os clientes conseguem reconectar rapidamente? Se o processo do broker, a máquina ou o caminho de rede falhar, quanto tempo leva até que os dispositivos consigam se conectar de novo?
2. O que acontece com o estado da sessão? As assinaturas e as mensagens QoS 1 e 2 enfileiradas para clientes offline são preservadas após a falha?
3. O que acontece com as mensagens em trânsito? Mensagens aceitas, mas ainda não entregues, são perdidas, entregues uma vez ou entregues duas vezes?

Essas perguntas têm respostas diferentes em arquiteturas diferentes, e um provedor excelente na primeira pode não prometer nada sobre a terceira. Seja preciso sobre qual delas você realmente precisa.

Arquiteturas Comuns de Alta Disponibilidade

Nenhum deles é o melhor em todos os casos. Muitos sistemas IoT confiáveis usam um único broker bem operado por partição, somado a clientes resilientes, porque a arquitetura mais simples é a que tem menos maneiras de falhar.

Onde um broker MQTT gerenciado se encaixa

Vale ser direto. A ConnectMQ não oferece clustering com replicação de mensagens, e sessões e mensagens enfileiradas não são persistidas entre reinícios do broker. Isso significa que você deve projetar os clientes para tolerar um reinício do broker reconectando, assinando novamente e republicando tudo o que for importante, o que é uma boa prática em qualquer broker.

O que ela oferece para o planejamento de disponibilidade é a escolha do modelo de implantação. Um plano Dedicated fornece um cluster isolado, de modo que o tráfego de outros tenants não afeta o seu. O BYOC executa o broker na sua própria conta de nuvem, gerenciado pela ConnectMQ, dentro da infraestrutura, da rede e das regiões que você já controla. Se você precisa de uma meta de disponibilidade específica, converse com a equipe sobre uma implantação Dedicated ou BYOC em vez de presumir um número.

O Que Acontece Durante um Failover

Quando um broker reinicia ou um cliente é movido para outro nó, a sequência típica é esta:

1. A conexão TCP cai. O cliente percebe imediatamente ou após o intervalo de keepalive.
2. Os demais assinantes recebem a mensagem Last Will, se o broker a processar antes da falha, ou uma atualização de status depois.
3. O cliente reconecta com backoff.
4. Se o broker ainda tiver a sessão, o CONNACK informa session present e as assinaturas continuam intactas. Caso contrário, o cliente começa com uma sessão limpa e precisa assinar novamente.
5. Mensagens publicadas enquanto o cliente estava offline só são entregues se o broker as manteve; caso contrário, foram perdidas.

A conclusão prática: nunca presuma que o passo 4 informará session present. Assine novamente a cada conexão e mantenha no cliente tudo o que você não pode perder até que seja confirmado.

Projetando Clientes para Alta Disponibilidade

Clientes resilientes transformam um failover do broker de incidente em um simples soluço. Os padrões abaixo funcionam em qualquer broker.

Assine novamente a cada conexão

Coloque as assinaturas no callback de conexão, e não no código de inicialização, para que sejam restauradas após cada reconexão, independentemente do estado da sessão.

Armazene localmente até a confirmação

Para dados importantes, mantenha uma fila local e remova um item somente depois que o broker confirmar uma publicação QoS 1. Nosso guia de MQTT store-and-forward aborda buffers persistentes em gateways.

Faça failover entre endpoints

Se você opera mais de um broker, por exemplo duas implantações independentes em locais diferentes, o cliente pode alternar entre eles. Veja um exemplo mínimo em Python com paho-mqtt 2.x que alterna endpoints, assina novamente ao conectar e mantém em memória as mensagens não confirmadas.

import json
import random
import threading
import time

import paho.mqtt.client as mqtt

ENDPOINTS = [("broker.connectmq.com", 8883), ("YOUR_SECONDARY_HOST", 8883)]
BASE = "acme/site1/line1/gw-01"
pending = {}              # mid -> (topic, payload), removido quando confirmado
lock = threading.Lock()

def send(client, topic, payload):
    with lock:
        info = client.publish(topic, payload, qos=1)
        pending[info.mid] = (topic, payload)

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("refused:", reason_code)
        return
    print("connected; session present:", flags.session_present)
    client.subscribe(f"{BASE}/cmd/#", qos=1)           # sempre assinar novamente
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    with lock:
        unacked = list(pending.values())
        pending.clear()
    for topic, payload in unacked:                       # reenviar dados não confirmados
        send(client, topic, payload)

def on_publish(client, userdata, mid, reason_code, properties):
    with lock:
        pending.pop(mid, None)

def on_message(client, userdata, msg):
    print("command:", msg.topic, msg.payload.decode())

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.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_publish = on_publish
client.on_message = on_message

index, delay = 0, 1
while True:
    host, port = ENDPOINTS[index % len(ENDPOINTS)]
    try:
        client.connect(host, port, keepalive=30)
    except OSError as exc:
        print(f"{host} unreachable: {exc}")
        index += 1
        time.sleep(delay + random.random())              # backoff com jitter
        delay = min(delay * 2, 60)
        continue
    delay = 1
    client.loop_start()
    time.sleep(2)                                        # aguardar o CONNACK
    while client.is_connected():
        reading = json.dumps({"ts": int(time.time()), "rpm": 1480})
        send(client, f"{BASE}/telemetry", reading)
        time.sleep(5)
    client.loop_stop()
    print(f"lost {host}, trying the next endpoint")
    index += 1

Em produção, você persistiria pending em disco e limitaria seu tamanho, mas a estrutura é a mesma. Como QoS 1 permite duplicatas, os receptores devem tolerar que uma mensagem chegue duas vezes após um failover. Observe que cada endpoint precisa de credenciais válidas para aquele broker.

Torne os comandos idempotentes

Após um failover, um comando QoS 1 pode chegar duas vezes. Inclua um ID de comando e ignore duplicatas no dispositivo.

Republique o estado, não dependa do broker para guardá-lo

Mensagens retidas de status e configuração são úteis, mas se o broker reiniciar sem persistência, elas precisam ser publicadas novamente. Faça os dispositivos republicarem o estado retido a cada conexão, como no exemplo.

Perguntas a Fazer a Qualquer Provedor MQTT

Use esta lista em avaliações e RFPs. Peça respostas por escrito e trate respostas vagas como "não".

1. Qual é a topologia de implantação do meu plano: nó único, ativo-passivo ou cluster?
2. Sessões e mensagens enfileiradas são persistidas após um reinício do broker?
3. As mensagens são replicadas entre nós antes de serem confirmadas?
4. Como os clientes são redirecionados após uma falha: mesmo hostname, mudança de DNS ou novo endpoint?
5. Qual é o tempo típico de recuperação após a falha de um nó, e ele é contratual?
6. Existe um SLA publicado, o que ele cobre e quais são os créditos?
7. Como são feitas manutenções e atualizações, e os clientes são desconectados?
8. Onde fica a página de status e como os incidentes são comunicados?
9. Posso executar uma implantação em um segundo local ou na minha própria conta de nuvem?
10. O que acontece com minha carga de trabalho se outro tenant se comportar mal em um plano compartilhado?

No nosso próprio serviço, as respostas às perguntas 2 e 3 são que persistência entre reinícios e replicação de mensagens não são oferecidas; quanto aos termos de SLA, pergunte diretamente à equipe. Nosso artigo sobre SLA de broker MQTT explica como interpretar a linguagem de um SLA, e o checklist de RFP para broker MQTT traz uma lista de avaliação mais longa.

Padrões Práticos de Alta Disponibilidade em um Broker MQTT Gerenciado

Combinando os conceitos acima, uma abordagem realista para a maioria das equipes fica assim:

• Escolha um broker MQTT gerenciado para que patches, TLS e falhas de máquina sejam responsabilidade de outra pessoa.
• Use uma implantação Dedicated se precisar de isolamento em relação a outros tenants.
• Use BYOC se o broker deve ficar na sua própria conta de nuvem, ao lado dos seus outros sistemas.
• Particione por site ou cliente (por exemplo, uma usina e uma mineradora do mesmo grupo) quando uma indisponibilidade não deve afetar todos.
• Construa todos os clientes com nova assinatura ao conectar, buffer local, comandos idempotentes e backoff com jitter.
• Monitore o estado das conexões, por exemplo via $SYS/broker/connection/{clientId}/state, e gere alertas quando dispositivos ficarem offline.

Para capacidade junto com disponibilidade, veja como escalar um broker MQTT e, para o panorama mais amplo de hospedagem, leia o guia de broker MQTT na nuvem.

Planeje a Disponibilidade do Seu MQTT com a ConnectMQ

A ConnectMQ é um broker MQTT gerenciado com opções Serverless, Dedicated e BYOC, para que você escolha o modelo de implantação que atende às suas necessidades de disponibilidade. Comece grátis em app.connectmq.com, sem cartão de crédito, construa clientes resilientes sobre ele e fale com a equipe quando precisar de uma implantação Dedicated ou BYOC.

Perguntas frequentes

O MQTT tem alta disponibilidade nativa?

Não. O protocolo MQTT define sessões, QoS e Last Will, mas a alta disponibilidade depende de como o broker é implantado e de como os clientes tratam as reconexões.

Minha sessão MQTT sobrevive a um reinício do broker?

Somente se o broker persistir as sessões. Muitas implantações, incluindo a nossa, não persistem sessões entre reinícios, então os clientes devem assinar novamente e republicar o estado importante a cada conexão.

Clustering é obrigatório para um sistema MQTT confiável?

Nem sempre. Clientes bem projetados, brokers particionados e implantações isoladas oferecem a muitos sistemas uma confiabilidade sólida sem um cluster replicado.

O que devo perguntar a um provedor sobre alta disponibilidade de broker MQTT?

Pergunte sobre topologia, persistência de sessão, replicação de mensagens, comportamento no failover, janelas de manutenção e termos de SLA por escrito. Obtenha as respostas por escrito antes de se comprometer.