MQTT est-il évolutif avec plus de 1000 clients?

Scénario
Périphérique IoT (actuellement le périphérique IPv4) qui envoie via le socket TCP une charge utile à un serveur une fois par jour. Le serveur a une adresse IP publique, l'appareil est derrière un routeur / NAT. Je vais utiliser un module basé sur ESP8266 (ie Olimex one)

Objectif
Le serveur doit pouvoir envoyer des données à n'importe quel client chaque fois qu'il en a besoin. Je ne suis pas intéressé par la communication directe de client à client (c'est-à-dire que je me connecte à un appareil depuis mon smartphone) comme la perforation est censée le faire.

Autres exigences
Les appareils IoT peuvent atteindre plusieurs milliers. Leur connexion Internet est fournie par de nombreux routeurs / modems compatibles 4G. Chacun traitera 10 à 20 clients.

Solution proposée
Pour autant que je sache, une solution courante est MQTT. Les clients envoient périodiquement des données au courtier (c'est-à-dire Mosquitto exécuté sur le serveur d'hébergement), qui à son tour met à jour l'application Web principale qui s'exécute sur le même serveur.

Question
L'approche MQTT convient-elle à un "grand" nombre d'appareils (1000+), la plupart derrière un routeur 4G?

1 000 clients peuvent être facilement traités par n'importe quel courtier MQTT décent; il y a une référence de Scalagent qui montre qu'un PC avec:

• un processeur Intel Core 2 Duo 3 GHz
• 4 Go de RAM

pourrait gérer 60 000 éditeurs exécutant Mosquitto. Cela dépasse largement les 1 000 éditeurs requis, donc même sur un serveur relativement faible, vous devriez toujours être en mesure de gérer le nombre requis.

Certains autres courtiers revendiquent des performances encore meilleures (avec une puissance de serveur proportionnellement supérieure, bien sûr), comme HiveMQ , qui prétendait gérer 10 millions d' éditeurs.

Les courtiers MQTT s'attendent généralement à une connexion persistante et expireront les clients qui n'envoient pas de réponses ping (ou autre activité) périodiquement. Vous pouvez vous déconnecter du réseau après la publication, mais, évidemment, vous ne pourrez plus rien recevoir si vous vous déconnectez.

MQTT prend en charge le concept de messages «retenus» qui pourraient être utiles. Le client Web peut publier quelque chose dans une rubrique avec l'indicateur conservé, et ce message sera ensuite stocké par le courtier. Chaque fois que vos clients se reconnectent et s'abonnent au sujet, ils recevront alors le message conservé (même s'il a été publié il y a des heures). Le message conservé est publié chaque fois qu'un client s'abonne à cette rubrique, ce qui peut vous aider si vous avez une connexion inégale et avez besoin d'un message à stocker jusqu'à ce que le client se reconnecte.

Vous pouvez utiliser des sessions persistantes de clients, par exemple un indicateur de nettoyage défini sur false lors de la connexion. Dans cet événement de scénario lorsque votre client est hors ligne, le courtier stocke le message dans son propre cache et le remet une fois que l'appareil se connecte.

À propos de la quantité - 10K est une quantité relativement faible, même pour un serveur. Vous pouvez configurer le serveur Linux pour contenir 500 000 connexions actives et si votre courtier sera basé sur le cloud, par exemple fourni en tant que service par un fournisseur, vous pouvez alors détenir même des millions de connexions actives.

Soit dit en passant, je pense que Mosquitto ou toute autre installation locale est un choix parfait pour le développement et les tests, mais lorsque vous entrerez en production, vous aurez besoin du courtier SaaS MQTT avec toutes les fonctionnalités telles que HA, la redondance, le basculement, etc.