Nie subskrybuj # - więc jak zrzucić wszystkie wiadomości do bazy danych za pomocą Mosquitto?


16

Blog HiveMQ wymienia pod „najlepszymi praktykami”, aby nie subskrybować wielopoziomowego symbolu wieloznacznego podczas próby zrzucenia wszystkich wiadomości do bazy danych. Twierdzą, że klient subskrybujący może nie być w stanie nadążyć za dużym obciążeniem wiadomości i proponują użycie wtyczki brokera do bezpośredniego połączenia się ze strumieniem wiadomości.

Czasami konieczne jest subskrybowanie wszystkich wiadomości przesyłanych przez brokera, na przykład podczas utrwalania ich wszystkich w bazie danych. Nie należy tego robić za pomocą klienta MQTT i subskrybowania wielopoziomowej karty wieloznacznej. Powodem jest to, że często subskrybujący klient nie jest w stanie przetworzyć obciążenia nadchodzących wiadomości. Zwłaszcza jeśli masz ogromną przepustowość. Naszym zalecanym rozwiązaniem jest wdrożenie rozszerzenia w brokerze MQTT, na przykład system wtyczek HiveMQ pozwala zaczepić się o zachowanie HiveMQ i dodać procedurę asynchroniczną do przetwarzania każdej przychodzącej wiadomości i utrwalania jej w bazie danych.

Czy tam też jest?

  • podobny system (rozszerzenie / wtyczka) dla brokera komarów,
  • inna zalecana metoda, która działa z komarem, lub
  • uzasadnione dowody, że takie podejście jest w ogóle niepotrzebne, tj. że klient subskrybujący #może zrobić dobrze?

/programming//q/31584613/3984613 nie rozwiązuje w sposób wyczerpujący tego pytania.

Odpowiedzi:


12

podobny system (rozszerzenie / wtyczka) dla brokera komarów

O ile mi wiadomo, nie ma wtyczki / rozszerzenia dla brokera mosquitto (przynajmniej żadnego open source)

kolejna zalecana metoda, która działa z komarem

Cóż, mogę powiedzieć na podstawie moich doświadczeń z brokerem Mosquitto i AWS IoT, możesz po prostu subskrybować „#”

Rozsądne dowody

Po zapoznaniu się z tym pytaniem byłem nieco ciekawy, jakie są ograniczenia przepustowości i czy istnieje potrzeba rozszerzenia systemu. Więc skonfigurowałem następujące:

  • 100 funkcji Lambda AWS, które działają jako wirtualne urządzenia końcowe do wysyłania losowych danych do bramki (instancja EC2 t2.nano500 MB pamięci RAM)
  • Co 60 sekund uruchamiane są funkcje publikujące dane w bramie do różnych tematów (lambdatoec2 / {VariableTopicNumberFrom1-100}
  • W instancji EC2 działa Mosquitto 1.4.10

W tej chwili widzę, że nie ma problemu z subskrybowaniem # bez żadnego systemu rozszerzenia. Ale znowu muszę przetestować kilka scenariuszy przypadków skrajnych (zaktualizuję odpowiedź, gdy je przetestuję).


„Prawidłowa” odpowiedź to testowanie. Jeśli można wykazać, że dodanie subskrybenta do # niekorzystnie wpływa na wydajność twojego systemu, ponownie skonfiguruj brokera, aby nie dopuszczał # subskrypcji. Poparłem tę odpowiedź, ponieważ @ bravokeyl właśnie to zrobił.
John Deters

11

Ta dyskusja na liście mailingowej openHAB wydaje się sugerować, że nie ma problemu z używaniem #jako subskrypcji do otrzymywania wszystkich wiadomości:

Podczas rozwiązywania problemów z urządzeniami MQTT przyszło mi do głowy, że czasami chciałbym widzieć wszystkie wiadomości MQTT, które widzi broker Mosquitto, zamiast na określony temat. Czy jest na to sposób?

Ktoś odpowiedział na to pytanie na liście Mosquitto; użyj znaku wieloznacznego. (#)

To pytanie dotyczące przepełnienia stosu sugeruje również tę samą metodę:

Subskrybowanie # daje subskrypcję na wszystko oprócz tematów zaczynających się od $ (zazwyczaj są to tematy kontrolne).

Oczywiście lepiej jest wiedzieć, co subskrybujesz jako pierwszy, i pamiętaj, że niektóre konfiguracje brokerów mogą uniemożliwić wyraźne subskrybowanie #.

Jak wskazał Bence Kaulics , specyfikacja zawiera #poprawne:

Komentarz nienormatywny

  • „#” Jest ważne i otrzyma każdy komunikat aplikacji

Szczerze mówiąc, kwestionuję, czy pierwotne roszczenie naprawdę ma w ogóle sens:

Powodem jest to, że często subskrybujący klient nie jest w stanie przetworzyć obciążenia nadchodzących wiadomości.

Jeśli tak, to w jaki sposób pośrednik może w pierwszej kolejności obsługiwać wiadomości? Tak długo, jak twój klient ma podobną charakterystykę wydajności do brokera, mocno wątpię, że byłoby możliwe przytłoczenie klienta, ponieważ ten poziom ruchu również przytłoczy brokera i spowoduje jego awarię w pierwszej kolejności.

Podsumowując, twierdzenie HiveMQ nie wydaje się poparte wieloma dowodami z innych źródeł, a kiedy zastanowisz się, co to właściwie znaczy, nie wydaje się to szczególnie logiczne.


10

Myślę, że ważne jest, aby wziąć pod uwagę, że istnieje wiele różnych przypadków użycia dla brokerów MQTT, podobnie jak w przypadku każdego oprogramowania.

Obsługa wiadomości czatu dla miliarda użytkowników (wielu użytkowników, stosunkowo niski wskaźnik wiadomości na użytkownika) różni się od systemu z kilkoma klientami, ale z wysokim współczynnikiem wiadomości, i oba różnią się od systemu automatyki domowej (niewielu klientów, niski wskaźnik wiadomości) .

HiveMQ myśli o aplikacjach o bardzo wysokiej liczbie klientów / wiadomości - w takim przypadku możliwości brokera prawie na pewno znacznie przewyższają możliwości klienta.

Jeśli chcesz zasubskrybować #swój system automatyki domowej, to raczej nie spowoduje problemów. W każdym razie możesz sprawdzić, czy broker używa nadmiernego procesora.

Podobnie jak w innych odpowiedziach, subskrybowanie #da ci wszystkie „normalne” tematy, czyli wszystko, co nie zaczyna się od $. Interpretuję to jako powiedzenie, że każdy temat zaczynający się od $jest osobnym drzewem, więc musisz się zapisać $SYS/#, $whatever/#aby uzyskać wszystko . Najprawdopodobniej i tak nie chcesz tego robić w przypadku normalnej aplikacji.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.