Non abbonarti a # - quindi come scaricare tutti i messaggi nel database con Mosquitto?


16

Il blog di HiveMQ elenca le "best practice" per non iscriversi al jolly multi livello quando si tenta di scaricare tutti i messaggi in un database. Sostengono che il client abbonato potrebbe non essere in grado di tenere il passo con un elevato carico di messaggi e propongono invece di utilizzare un plug-in broker per agganciarsi direttamente al flusso di messaggi.

A volte è necessario abbonarsi a tutti i messaggi, che vengono trasferiti tramite il broker, ad esempio quando persistono tutti in un database. Questo non dovrebbe essere fatto utilizzando un client MQTT e sottoscrivendo il carattere jolly multi livello. Il motivo è che spesso il client abbonato non è in grado di elaborare il carico di messaggi che sta arrivando. Soprattutto se si dispone di un volume elevato. La nostra soluzione consigliata è quella di implementare un'estensione nel broker MQTT, ad esempio il sistema di plugin di HiveMQ consente di agganciare il comportamento di HiveMQ e aggiungere una routine asincrona per elaborare ogni messaggio in arrivo e mantenerlo in un database.

C'è neanche

  • un sistema simile (estensione / plugin) per il broker mosquitto,
  • un altro metodo raccomandato che funziona con mosquitto, o
  • prove ragionevoli che questo approccio non è affatto necessario, cioè che un cliente che si abbona #può fare bene?

/programming//q/31584613/3984613 non affronta in modo esauriente questa domanda.

Risposte:


12

un sistema simile (estensione / plugin) per il broker mosquitto

Per quanto ne so non esiste alcun plug-in / estensione per il broker mosquitto (almeno non uno opensource)

un altro metodo raccomandato che funziona con mosquitto

Bene, posso dire per esperienza con il broker Mosquitto e AWS IoT, puoi semplicemente iscriverti direttamente a '#'

Prove ragionevoli

Dopo aver esaminato questa domanda, ero un po 'curioso di conoscere i limiti di throughput e scoprire se è necessario un sistema di estensione. Quindi ho impostato quanto segue:

  • 100 funzioni AWS Lambda che fungono da dispositivi finali virtuali per inviare alcuni dati casuali al gateway (istanza EC2 t2.nano500 MB di RAM)
  • Ogni 60 secondi vengono attivate funzioni per pubblicare dati sul gateway su argomenti diversi (lambdatoec2 / {VariableTopicNumberFrom1-100}
  • L'istanza EC2 esegue Mosquitto 1.4.10

A partire da ora, vedo che non ci sono problemi ad abbonarsi a # senza alcun sistema di estensione. Ma ancora una volta devo ancora provare alcuni scenari limite (aggiornerò la risposta una volta testati).


La risposta "corretta" sta testando. Se si può dimostrare che le prestazioni del sistema sono influenzate negativamente aggiungendo un abbonato a #, quindi riconfigurare il broker per non consentire # abbonamenti. Ho votato a favore di questa risposta perché @bravokeyl ha fatto esattamente questo.
John Deters,

11

Questa discussione sulla mailing list di openHAB sembra suggerire che non ci sono problemi con l'utilizzo #come abbonamento per ricevere tutti i messaggi:

Durante la risoluzione dei problemi dei dispositivi MQTT, mi è venuto in mente che a volte vorrei poter vedere tutti i messaggi MQTT che il broker Mosquitto vede, anziché uno su un argomento specifico. C'è un modo per fare questo?

Qualcuno ha risposto a questa domanda per te nell'elenco Mosquitto; usa un carattere jolly. (#)

Questa domanda Stack Overflow suggerisce anche lo stesso metodo:

L'iscrizione a # ti dà un abbonamento a tutto tranne che agli argomenti che iniziano con $ (questi sono comunque argomenti di controllo comunque).

Tuttavia, è meglio sapere a cosa si sta abbonando prima, ovviamente, e notare che alcune configurazioni di broker potrebbero non consentire l'iscrizione esplicita a #.

Come sottolineato da Bence Kaulics , la specifica afferma che #è valido:

Commento non normativo

  • "#" È valido e riceverà tutti i messaggi dell'applicazione

Onestamente, contesto se l'affermazione originale abbia davvero molto senso:

Il motivo è che spesso il client abbonato non è in grado di elaborare il carico di messaggi che sta arrivando.

In tal caso, come potrebbe il broker gestire i messaggi in primo luogo? Fintanto che il tuo cliente ha caratteristiche prestazionali simili al broker, dubito fortemente che sarebbe possibile sopraffare il client, perché quel livello di traffico avrebbe anche sopraffatto il broker e causerebbe il primo arresto anomalo.

In sintesi, l'affermazione di HiveMQ non sembra essere supportata da molte prove provenienti da altre fonti e, se si considera cosa significherebbe effettivamente, non sembra particolarmente logico.


10

Penso che sia importante considerare che ci sono molti casi d'uso diversi per i broker MQTT, come con qualsiasi software.

La gestione dei messaggi di chat per un miliardo di utenti (molti utenti, percentuale di messaggi relativamente bassa per utente) è diversa da un sistema con pochi client ma con una frequenza di messaggi elevata e sono entrambi diversi da un sistema di automazione domestica (pochi client, velocità di messaggio bassa) .

HiveMQ sta pensando alle applicazioni client / message rate molto elevate - nel qual caso la capacità del broker supera quasi sicuramente quella di un client.

Se si desidera abbonarsi al #sistema di automazione domestica, è molto improbabile che causi problemi. È possibile verificare e verificare se il broker utilizza CPU eccessiva in ogni caso.

Come nelle altre risposte, l'abbonamento #ti fornirà tutti gli argomenti "normali", ovvero tutto ciò che non inizia con a $. Interpreto le specifiche, come dire che ogni argomento che inizia con $un albero intero separata in se stessa, in modo che avrebbe dovuto sottoscrivere $SYS/#, $whatever/#per ottenere tutto . Molto probabilmente non vorrai farlo comunque per una normale applicazione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.