Czy MQTT jest skalowalny dla ponad 1000 klientów?


10

Scenariusz
Urządzenie IoT (obecnie urządzenie IPv4), które wysyła przez gniazdo TCP ładunek do serwera raz dziennie. Serwer ma publiczny adres IP, urządzenie znajduje się za routerem / NAT. Użyję modułu opartego na ESP8266 (tj. Olimex)

Celem serwer powinien być w stanie wysyłać dane do każdego klienta, gdy zajdzie potrzeba. Nie interesuje mnie bezpośrednia komunikacja klient-klient (tj. Połączenie urządzenia z moim smartfonem), tak jak powinno to robić dziurkowanie.

Inne wymagania
Urządzenia IoT mogą wzrosnąć nawet do kilku tysięcy. Ich połączenie internetowe zapewnia wiele routerów / modemów z obsługą 4G. Każdy będzie obsługiwał 10-20 klientów.

Proponowane rozwiązanie
O ile rozumiem, powszechnym rozwiązaniem jest MQTT. Klienci okresowo wysyłają dane do brokera (tj. Mosquitto działającego na serwerze hostingowym), który z kolei aktualizuje główną aplikację internetową działającą na tym samym serwerze.

Pytanie
Czy podejście MQTT jest odpowiednie dla „dużej” liczby urządzeń (1000+), większość z nich za routerem 4G?


Lepiej zadać pytanie (1) osobno i po prostu zadać pytanie (2), które pasuje do twojego tytułu w treści pytania. W ten sposób możemy szczegółowo odpowiedzieć na każde pytanie. Możesz dołączyć swój kontekst ponownie do nowego pytania lub link do tego, jeśli to pomoże.
Aurora0001

1
Pytanie zmieniło się i dodano drugie.
Mark

Z brzmienia tego wynika, że ​​nawet jeśli wystąpiły problemy z obciążeniem serwera związane z utrzymywaniem dużej liczby otwartych połączeń, system byłby dość zgodny z topologią typu drzewa, w której klienci łączą się z serwerami pośrednimi, które przechowują odpowiednie sesje i przekazują raczej rzadki ruch w górę i w dół do wyższych serwerów w jednym potoku. Prawdopodobnie możesz zrobić pierwszą warstwę tego lokalnie w routerach 4G.
Chris Stratton

Odpowiedzi:


7

1000 porządnych brokerów MQTT może łatwo obsłużyć 1000 klientów; istnieje Scalagent, który pokazuje, że komputer z:

  • procesor Intel Core 2 Duo 3 GHz
  • 4 GB pamięci RAM

może obsłużyć 60 000 wydawców korzystających z Mosquitto. Jest to znacznie więcej niż wymagane 1000 wydawców, więc nawet na stosunkowo słabym serwerze powinieneś być w stanie obsłużyć wymaganą liczbę.

Niektórzy inni brokerzy twierdzą nawet o lepszej wydajności (oczywiście przy odpowiednio większej mocy serwera), na przykład HiveMQ , który twierdzi, że obsługuje 10 milionów wydawców.

Brokerzy MQTT zazwyczaj oczekują trwałego połączenia i przekroczą limit czasu klientów, którzy nie wysyłają okresowo odpowiedzi ping (lub innych działań). Możesz odłączyć się od sieci po opublikowaniu, ale oczywiście nie będziesz w stanie niczego otrzymać, jeśli się rozłączysz.

MQTT obsługuje koncepcję „zatrzymanych” wiadomości, które mogą być przydatne. Klient WWW może opublikować coś w temacie z zachowaną flagą, a następnie broker zapisze tę wiadomość. Za każdym razem, gdy klienci ponownie się połączą i zasubskrybują ten temat, otrzymają zachowaną wiadomość (nawet jeśli została opublikowana kilka godzin temu). Zatrzymany komunikat jest publikowany za każdym razem, gdy klient subskrybuje ten temat, więc może ci to pomóc, jeśli masz nieregularne połączenie i potrzebujesz wiadomości, która będzie przechowywana do momentu ponownego połączenia się klienta.


Na pewno źle to wytłumaczyłem. Tylko serwer (komercyjna usługa hostingowa) powinien obsługiwać ponad 1000 klientów. Istnieje wiele routerów 4G w różnych miejscach, a każdy obsługuje tylko 10-20 klientów.
Mark

Och, źle odczytałem - moja wina, @Mark, założyłem, że masz na myśli wszystkie za jednym routerem 4G. W takim przypadku dokonam edycji.
Aurora0001

Nie rozumiem jeszcze w pełni podstawowego kodu MQTT - bałam się połączeń 4G: czy MQTT wymaga trwałych połączeń internetowych? Prawdopodobnie sieć będzie niestabilna ...
Mark

Edytowałem z pewnymi sugestiami, @Mark; daj mi znać, jeśli to wskaże ci właściwy kierunek.
Aurora0001

1
Tak, teraz jest wyraźniej. Zamierzam przeprowadzić dalsze poszukiwania na ten temat i jeśli nadal potrzebuję pomocy, zadam kolejne pytanie. Wielkie dzięki.
Mark

5

Możesz używać trwałych sesji od klientów, np. Czysta flaga ustawiona na false podczas łączenia. W takim scenariuszu, gdy klient jest w trybie offline, broker zbuforuje komunikat do własnej pamięci podręcznej i dostarczy go po połączeniu urządzenia.

O ilości - 10 000 to stosunkowo niska kwota nawet dla jednego serwera. Możesz skonfigurować serwer Linux, aby utrzymywał 500 000 aktywnych połączeń, a jeśli twój broker będzie działał w chmurze, np. Zapewniany jako usługa przez jakiegoś dostawcę, możesz utrzymywać z nim nawet miliony aktywnych połączeń.

Nawiasem mówiąc, myślę, że Mosquitto lub jakakolwiek inna instalacja lokalna jest idealnym wyborem do programowania i testowania, ale kiedy wejdziesz do produkcji, potrzebujesz brokera SaaS MQTT ze wszystkimi funkcjami, takimi jak HA, redundancja, przełączanie awaryjne itp.


Nie sądzę, że broker SaaS MQTT jest zawsze najlepszy do produkcji. Większość profesjonalnych (samo hostujących) brokerów MQTT obsługuje HA, redundancję i przełączanie awaryjne na dużą skalę, zachowując jednocześnie pełną zgodność MQTT. Niektórzy brokerzy SaaS nie obsługują wszystkich funkcji MQTT. Jeśli przeprowadzisz test przeciwko lokalnemu komarowi, a następnie udasz się do dostawcy SaaS, istnieje szansa, że ​​rzeczy nie działają w produkcji zgodnie z przeznaczeniem.
Dominik Obermaier

Jak zwykle są zalety i wady obu opcji. Oczywiste jest, że każdy broker SaaS wymaga doskonałego komunikatywnego zespołu, długoterminowych testów na wczesnym etapie rozwoju produktu, wyraźnych gwarancji dostępności i różnych umów SLA. Utrzymanie własnego brokera jest również dobrym sposobem, ale świat przechodzi do usług. Albo dołożysz wszelkich starań i będziesz najbardziej kompetentny w swoim produkcie, który korzysta z brokera w jego ramach, albo poświęcisz czas i pieniądze na bycie super doświadczonym administratorem brokera MQTT (i nigdy nie będziesz jego programistą!). Tylko kwestia wyboru +)
Shal
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.