O MQTT é escalável com mais de 1000 clientes?

Cenário
Dispositivo IoT (atualmente dispositivo IPv4) que envia via soquete TCP uma carga útil para um servidor uma vez por dia. O servidor tem um endereço IP público, o dispositivo está atrás de um roteador / NAT. Vou usar um módulo baseado no ESP8266 (ou seja, o Olimex one)

Objetivo
O servidor deve poder enviar dados para qualquer cliente sempre que necessário. Não estou interessado em comunicação direta de cliente para cliente (por exemplo, conectar um dispositivo a partir do meu smartphone) como o furador deve fazer.

Outros requisitos
Os dispositivos IoT podem crescer até vários milhares. Sua conexão com a Internet é fornecida por muitos roteadores / modems habilitados para 4G. Cada um irá lidar com 10-20 clientes.

Solução proposta
Até onde eu entendo, uma solução comum é o MQTT. Os clientes enviam periodicamente dados para o broker (por exemplo, Mosquitto em execução no servidor de hospedagem), que, por sua vez, atualiza o aplicativo Web principal que é executado no mesmo servidor.

Pergunta
A abordagem MQTT é adequada para um número "grande" de dispositivos (mais de 1000), a maioria deles atrás de um roteador 4G?

mqtt wifi routers

— Marca
fonte

Talvez seja melhor fazer a pergunta (1) separadamente e apenas fazer a pergunta (2) que corresponde ao seu título no corpo da pergunta. Dessa forma, podemos resolver cada uma das suas perguntas separadamente em detalhes. Você pode incluir seu contexto novamente na nova pergunta ou vincular-se a essa, se ajudar.

— Aurora0001

A pergunta mudou e adicionou a segunda.

— Mark

Pelo que parece, mesmo que você tenha problemas com a carga do servidor com um grande número de conexões abertas, seu sistema seria bastante compatível com um tipo de árvore de topologia em que os clientes se conectam a servidores intermediários que mantêm as sessões correspondentes e passam a tráfego pouco frequente para cima e para baixo em servidores mais altos em um único canal cada. Você provavelmente poderia até fazer a primeira camada disso localmente em seus roteadores 4G.

— 22418 Chris Stratton

Respostas:

1.000 clientes podem ser facilmente manipulados por qualquer corretor MQTT decente; existe uma referência da Scalagent que mostra que um PC com:

um processador Intel Core 2 Duo de 3 GHz
4 GB de RAM

poderia lidar com 60.000 publicadores executando o Mosquitto. Isso excede em muito os 1.000 editores necessários, portanto, mesmo em um servidor relativamente fraco, você ainda poderá lidar com o número necessário.

Alguns outros corretores reivindicam desempenho ainda melhor (com poder de servidor correspondentemente maior, é claro), como o HiveMQ , que alegou lidar com 10 milhões de publicadores.

Os agentes do MQTT geralmente esperam uma conexão persistente e atingem o tempo limite de clientes que não enviam respostas de ping (ou outra atividade) periodicamente. Você pode se desconectar da rede após a publicação, mas, obviamente, não poderá receber nada se se desconectar.

O MQTT suporta o conceito de mensagens 'retidas' que podem ser úteis. O cliente da web pode publicar algo em um tópico com o sinalizador retido e essa mensagem será armazenada pelo broker. Sempre que seus clientes se reconectarem e se inscreverem no tópico, eles receberão a mensagem retida (mesmo que tenha sido publicada horas atrás). A mensagem retida é publicada toda vez que um cliente se inscreve nesse tópico, para que possa ajudá-lo se você tiver uma conexão irregular e precisar que uma mensagem seja armazenada até que o cliente se reconecte.

— Aurora0001
fonte

Eu certamente expliquei errado. Somente o servidor (serviço de hospedagem comercial) deve lidar com mais de 1000 clientes. Existem muitos roteadores 4G em diferentes locais, e cada um processa apenas 10 a 20 clientes.

— Mark

Ah, eu interpretei errado - minha culpa, @Mark, presumi que você quis dizer tudo isso por trás de um roteador 4G. Vou editar isso nesse caso.

— Aurora0001

Ainda não compreendo completamente o código subjacente do MQTT - eu estava com medo das conexões 4G: o MQTT requer conexões persistentes com a Internet? Provavelmente, a rede ficará instável ... #

— Mark

Eu editei com algumas sugestões, @Mark; deixe-me saber se isso lhe indica a direção certa.

— Aurora0001

Sim, está mais claro agora. Vou fazer algumas pesquisas adicionais sobre esse tópico e, se ainda precisar de ajuda, farei outra pergunta. Muito obrigado.

— Mark

Você pode usar sessões persistentes de clientes, por exemplo, sinalizador limpo definido como falso ao conectar. Nesse cenário, quando o cliente estiver offline, o broker armazenará a mensagem em buffer no próprio cache e a entregará assim que o dispositivo for conectado.

Sobre a quantidade - 10K é uma quantidade relativamente baixa, mesmo para um servidor. Você pode configurar o servidor Linux para armazenar conexões ativas de 500K e se o seu broker for baseado na nuvem, por exemplo, fornecido como serviço por algum provedor, você poderá armazenar até milhões de conexões ativas.

A propósito, acho que o Mosquitto ou qualquer outra instalação local é a escolha perfeita para desenvolvimento e teste, mas quando você entra em produção, precisa do broker SaaS MQTT com todos os recursos, como alta disponibilidade, redundância, failover etc.

— shal
fonte

Não acho que um corretor SaaS MQTT seja sempre o melhor para produção. A maioria dos agentes profissionais (auto-hospedados) do MQTT suporta HA, redundância e failover em escala, mantendo total compatibilidade com o MQTT. Alguns intermediários SaaS não suportam todos os recursos do MQTT. Se você testar um mosquito local e depois procurar um fornecedor de SaaS, é provável que as coisas não funcionem na produção conforme o esperado.

— Dominik Obermaier 22/02

Como de costume, existem prós e contras de ambas as opções. Obviamente, qualquer corretor SaaS exige uma equipe de comunicação perfeita, testes a longo prazo no estágio inicial do desenvolvimento do produto, garantias claras de tempo de atividade e vários SLA. Manter o próprio corretor também é uma boa maneira, mas o mundo está entrando em serviços. Você fará esforços e seja mais competente com o seu produto que usa o broker como parte dele ou gastará seu tempo e dinheiro em ser um administrador super experiente do MQTT-broker (e nunca será seu desenvolvedor!). Apenas uma questão de escolha +)

— shal