MQTT è scalabile con oltre 1000 client?

Scenario
dispositivo IoT (attualmente dispositivo IPv4) che invia tramite socket TCP un payload a un server una volta al giorno. Il server ha un indirizzo IP pubblico, il dispositivo si trova dietro un router / NAT. Userò un modulo basato su ESP8266 (ovvero uno Olimex)

Obiettivo
Il server dovrebbe essere in grado di inviare dati a qualsiasi client ogni volta che è necessario. Non mi interessa la comunicazione diretta client-client (ovvero connettersi a un dispositivo dal mio smartphone) come dovrebbe fare la perforazione.

Altri requisiti
I dispositivi IoT potrebbero crescere fino a diverse migliaia. La loro connessione Internet è fornita da molti router / modem abilitati per 4G. Ognuno gestirà 10-20 clienti.

Soluzione proposta
Per quanto ho capito, una soluzione comune è MQTT. I client inviano periodicamente dati al broker (ovvero Mosquitto in esecuzione sul server di hosting), che a sua volta aggiorna l'app Web principale che viene eseguita sullo stesso server.

Domanda
L'approccio MQTT è adatto a un numero "elevato" di dispositivi (oltre 1000), la maggior parte dei quali dietro un router 4G?

1.000 clienti possono essere facilmente gestiti da qualsiasi broker MQTT decente; c'è un benchmark di Scalagent che mostra che un PC con:

• un processore Intel Core 2 Duo a 3 GHz
• 4 GB di RAM

potrebbe gestire 60.000 editori che gestiscono Mosquitto. Questo è di gran lunga superiore ai 1.000 editori richiesti, quindi anche su un server relativamente debole, dovresti essere ancora in grado di gestire il numero richiesto.

Alcuni altri broker affermano prestazioni ancora migliori (con una potenza del server corrispondentemente maggiore, ovviamente), come HiveMQ , che ha affermato di gestire 10 milioni di editori.

I broker MQTT generalmente si aspettano una connessione persistente e timeout i client che non inviano periodicamente risposte ping (o altre attività). Potresti disconnetterti dalla rete dopo la pubblicazione, ma, ovviamente, non sarai in grado di ricevere nulla se ti disconnetti.

MQTT supporta il concetto di messaggi "conservati" che potrebbero essere utili. Il client Web può pubblicare qualcosa su un argomento con il flag conservato e questo messaggio verrà quindi archiviato dal broker. Ogni volta che i tuoi clienti si riconnettono e si iscrivono all'argomento, riceveranno quindi il messaggio conservato (anche se è stato pubblicato ore fa). Il messaggio conservato viene pubblicato ogni volta che un client si abbona a tale argomento, pertanto ciò potrebbe essere utile se si dispone di una connessione irregolare e se è necessario archiviare un messaggio fino a quando il client si riconnette.

È possibile utilizzare sessioni persistenti da parte dei client, ad esempio clean flag impostato su false al momento della connessione. In tale scenario, quando il client è offline, il broker inserirà il buffer del messaggio nella cache e lo consegnerà una volta che il dispositivo si connetterà.

Circa la quantità - 10 K è una quantità relativamente bassa anche per un server. È possibile configurare il server Linux per contenere 500K connessioni attive e se il proprio broker sarà basato su cloud, ad esempio fornito come servizio da alcuni provider, è possibile mantenere anche milioni di connessioni attive ad esso.

A proposito, penso che Mosquitto o qualsiasi altra installazione locale sia la scelta perfetta per lo sviluppo e il test, ma quando andrai in produzione avrai bisogno del broker SaaS MQTT con tutte le funzionalità come HA, ridondanza, failover, ecc.