Чи можна MQTT масштабуватись з 1000+ клієнтами?

Пристрій сценарію IoT (в даний час IPv4 пристрій), який надсилає через TCP-розетку корисне навантаження на сервер один раз на день. Сервер має загальнодоступну IP-адресу, пристрій знаходиться за маршрутизатором / NAT. Я буду використовувати модуль на базі ESP8266 (тобто Olimex один)

Мета сервер повинен мати можливість передавати дані будь-якого клієнта , коли це необхідно. Мене не цікавить пряме спілкування «клієнт-клієнт» (тобто підключення до пристрою зі свого смартфона), як це передбачається.

Інші вимоги
Пристрої IoT можуть вирости до кількох тисяч. Їх підключення до Інтернету забезпечується багатьма маршрутизаторами / модемами з підтримкою 4G. Кожен з них буде обробляти 10-20 клієнтів.

Пропоноване рішення
Наскільки я розумію, поширеним рішенням є MQTT. Клієнти періодично надсилають дані брокеру (тобто Mosquitto, що працює на хостинговому сервері), що в свою чергу оновлює основний веб-додаток, який працює на тому ж сервері.

Запитання
Чи підходить підхід MQTT для "великої" кількості пристроїв (1000+), більшість із них за маршрутизатором 4G?

mqtt wifi routers

— Позначити
джерело

Можливо, краще задати питання (1) окремо і просто задати питання (2), яке відповідає вашому заголовку в тілі питань. Таким чином, ми можемо детально вирішити кожне ваше питання окремо. Ви можете знову включити свій контекст у нове запитання або посилання на це, якщо це допоможе.

— Aurora0001

Питання змінилось і додало друге.

— Марк

З огляду на це, навіть якщо ви зіткнулися з проблемами завантаження сервера з великою кількістю відкритих з'єднань, ваша система була б цілком сумісна з деревним типом топології, де клієнти підключаються до проміжних серверів, які проводять відповідні сеанси і проходять досить нечастий трафік вгору і вниз на вищі сервери в одну трубу кожен. Можливо, ви могли навіть зробити перший рівень цього локально у своїх маршрутизаторах 4G.

— Кріс Страттон

Відповіді:

1000 клієнтів можуть легко впоратися з будь-яким порядним брокером MQTT; є тест від Scalagent, який показує, що ПК із:

процесор Intel Core 2 Duo 3 ГГц
4 ГБ оперативної пам’яті

міг би попрацювати 60 000 видавців, котрі керують Москітто. Це набагато перевищує необхідні 1000 видавців, тому навіть на відносно слабкому сервері ви все ще можете мати можливість обробляти необхідну кількість.

Деякі інші брокери заявляють про ще більшу продуктивність (звичайно, з відповідно більшою потужністю сервера), наприклад HiveMQ , який стверджував, що обробляє 10 мільйонів видавців.

Як правило, брокери MQTT очікують на постійне підключення і періодично очікують клієнтів, які періодично не надсилають відповіді на пінг (або іншу активність). Ви можете відключитись від мережі після публікації, але, очевидно, тоді ви нічого не зможете отримати, якщо відключитеся.

MQTT підтримує концепцію "збережених" повідомлень, яка може бути корисною. Веб-клієнт може опублікувати щось до теми із збереженим прапором, і це повідомлення буде зберігатися брокером. Щоразу, коли ваші клієнти знову підключаться та підписуються на тему, вони отримуватимуть збережене повідомлення (навіть якщо воно було опубліковано години тому). Збережене повідомлення публікується щоразу, коли клієнт підписується на цю тему, тож це може допомогти вам, якщо у вас патч-з'єднання та потрібне повідомлення для зберігання, поки клієнт не підключиться знову.

— Aurora0001
джерело

Я напевно пояснив це неправильно. Тільки сервер (комерційний хостинг-сервіс) повинен обслуговувати 1000+ клієнтів. Існує багато маршрутизаторів 4G в різних місцях, і кожен з них може обслуговувати лише 10-20 клієнтів.

— Марк

О, я неправильно прочитав - моя вина, @Mark, я припустив, що ти маєш на увазі їх усіх за одним маршрутизатором 4G. Я відредагую це у такому випадку.

— Aurora0001

Я ще не повністю розумію базовий код MQTT - я побоювався з приводу підключень 4G: чи потрібен MQTT постійне підключення до Інтернету? Ймовірно, мережа буде нестабільною ...

— Марк

Я відредагував кілька пропозицій, @Mark; дайте мені знати, чи це вказує на вас у правильному напрямку.

— Aurora0001

Так, зараз зрозуміліше. Я збираюся зробити кілька додаткових пошуків на цю тему, і якщо мені ще потрібна допомога, я поставлю ще одне питання. Дуже дякую.

— Марк

Ви можете використовувати постійні сеанси від клієнтів, наприклад, чистий прапор встановлений на помилковий при підключенні. У такому випадку, коли ваш клієнт офлайн-брокер буде буферне повідомлення для цього у власний кеш і доставить його, коли пристрій підключиться.

Щодо кількості - 10K - це порівняно низька кількість навіть для одного сервера. Ви можете налаштувати Linux-сервер так, щоб він підтримував 500K активних з'єднань, і якщо ваш брокер буде заснований на хмарі, наприклад, наданий послугою якогось провайдера, то ви можете утримувати навіть мільйони активних підключень до нього.

До речі, я вважаю, що Mosquitto або будь-яка інша локальна установка є ідеальним вибором для розробки та тестування, але коли ви підете на виробництво, вам потрібен брокер SaaS MQTT з усіма такими функціями, як HA, резервування, відмовка тощо.

— міл
джерело

Я не думаю, що брокер SaaS MQTT завжди найкращий для виробництва. Більшість професійних MQTT брокерів підтримують HA, надмірність та відмову в масштабі, зберігаючи повну сумісність MQTT. Деякі брокери SaaS не підтримують усі функції MQTT. Якщо ви протестуєте проти місцевого комара, а потім звернетесь до постачальника SaaS, велика ймовірність, що в виробництві все не працює за призначенням.

— Домінік Обермайер

Як завжди, існують плюси і мінуси обох варіантів. Очевидно, що будь-який брокер SaaS потребує досконалої комунікативної команди, довгострокових тестувань на ранній стадії розробки продукту, чітких гарантій безперервного часу та різноманітних угод про домовленість. Підтримка власного брокера - це також приємний спосіб, але світ переходить у сферу послуг. Або ви докладете зусиль і будете найбільш компетентні зі своїм продуктом, який використовує брокера як частину його, або ви витратите свій час і гроші на те, щоб бути супер досвідченим адміністратором брокера MQTT (і ніколи не бути його розробником!). Просто питання вибору +)

— малий