Ne vous abonnez pas à # - alors comment vider tous les messages dans la base de données avec Mosquitto?

Le blog de HiveMQ répertorie les "meilleures pratiques" pour ne pas s'abonner au caractère générique à plusieurs niveaux lors de la tentative de vidage de tous les messages dans une base de données. Ils affirment que le client abonné peut ne pas être en mesure de suivre une charge élevée de messages et proposent d'utiliser un plugin de courtier pour se connecter directement au flux de messages.

Parfois, il est nécessaire de s'abonner à tous les messages, qui sont transférés via le courtier, par exemple lorsqu'ils sont tous persistants dans une base de données. Cela ne doit pas être fait en utilisant un client MQTT et en vous abonnant au caractère générique à plusieurs niveaux. La raison en est que souvent le client abonné n'est pas en mesure de traiter la charge de messages qui arrive. Surtout si vous avez un débit massif. Notre solution recommandée consiste à implémenter une extension dans le courtier MQTT, par exemple le système de plug-in de HiveMQ vous permet de vous connecter au comportement de HiveMQ et d'ajouter une routine asynchrone pour traiter chaque message entrant et le conserver dans une base de données.

Y a-t-il non plus

• un système similaire (extension / plugin) pour le courtier moustique,
• une autre méthode recommandée qui fonctionne avec le moustique, ou
• une preuve raisonnable que cette approche n'est pas nécessaire du tout, c'est-à-dire qu'un client abonné #peut très bien faire?

^{/programming//q/31584613/3984613 ne répond pas à cette question de manière exhaustive.}

un système similaire (extension / plugin) pour le courtier moustique

Pour autant que je sache, il n'y a pas de plugin / extension pour Mosquitto Broker (au moins pas de logiciel open source)

une autre méthode recommandée qui fonctionne avec le moustique

Eh bien, je peux dire d'après mon expérience avec Mosquitto Broker et AWS IoT, vous pouvez simplement vous abonner directement à '#'

Preuve raisonnable

Après avoir examiné cette question, j'étais un peu curieux de connaître les limites de débit et de savoir s'il y avait un besoin d'un système d'extension. J'ai donc mis en place ce qui suit:

• 100 fonctions AWS Lambda qui agissent comme des terminaux virtuels pour envoyer des données aléatoires à la passerelle (instance EC2 t2.nano500 Mo de RAM)
• Toutes les 60 secondes, les fonctions sont déclenchées pour publier des données sur la passerelle vers différents sujets (lambdatoec2 / {VariableTopicNumberFrom1-100}
• L'instance EC2 exécute Mosquitto 1.4.10

Pour l'instant, je vois qu'il n'y a aucun problème à s'abonner à # sans aucun système d'extension. Mais encore une fois, je dois encore tester quelques scénarios de cas marginaux (je mettrai à jour la réponse une fois que je les testerai).

Cette discussion sur la liste de diffusion openHAB semble suggérer qu'il n'y a aucun problème à utiliser #comme abonnement pour recevoir tous les messages:

Lors du dépannage des périphériques MQTT, il m'est venu à l'esprit que parfois je souhaitais voir tous les messages MQTT que le courtier Mosquitto voit, au lieu d'un sur un sujet spécifique. Y a-t-il un moyen de faire cela?

Quelqu'un a répondu à cette question pour vous sur la liste Mosquitto; utilisez un caractère générique. (#)

Cette question Stack Overflow suggère également la même méthode:

S'abonner à # vous donne un abonnement à tout sauf aux sujets qui commencent par un $ (ce sont des sujets de contrôle de toute façon).

Il est préférable de savoir à quoi vous vous abonnez en premier, bien sûr, et notez que certaines configurations de courtier peuvent interdire l'abonnement à # explicitement.

Comme l'a souligné Bence Kaulics , la spécification précise que# est valide:

Commentaire non normatif

• "#" Est valide et recevra chaque message d'application

Honnêtement, je conteste que la revendication initiale ait vraiment beaucoup de sens:

La raison en est que souvent le client abonné n'est pas en mesure de traiter la charge de messages qui arrive.

Si tel est le cas, comment le courtier pourrait-il gérer les messages en premier lieu? Tant que votre client a des caractéristiques de performances similaires au courtier, je fortement doute qu'il soit possible de submerger le client, car ce niveau de trafic submergerait également le courtier et provoquerait le blocage en premier.

En résumé, la revendication HiveMQ ne semble pas être appuyée par de nombreuses preuves provenant d'autres sources et, lorsque vous considérez ce que cela signifierait réellement, cela ne semble pas particulièrement logique.

Je pense qu'il est important de considérer qu'il existe de nombreux cas d'utilisation différents pour les courtiers MQTT, comme avec n'importe quel logiciel.

La gestion des messages de discussion pour un milliard d'utilisateurs (de nombreux utilisateurs, un taux de messages relativement faible par utilisateur) est différente d'un système avec peu de clients mais un taux de messages élevé, et ils sont tous deux différents d'un système domotique (peu de clients, faible taux de messages) .

HiveMQ pense aux applications à très haut débit client / message - auquel cas la capacité du courtier dépasse certainement de loin celle d'un client.

Si vous souhaitez vous abonner # votre système domotique, il est très peu probable qu'il cause des problèmes. Vous pouvez vérifier et voir si le courtier utilise un processeur excessif dans tous les cas.

Comme dans les autres réponses, vous abonner #vous donnera tous les sujets «normaux», c'est-à-dire tout ce qui ne commence pas par un $. J'interprète la spécification comme disant que chaque sujet commençant par $est un arbre entièrement séparé en soi, vous devez donc vous abonner à $SYS/#, $whatever/#pour tout obtenir . Vous ne voudrez probablement pas le faire de toute façon pour une application normale.