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?

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.

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.