Не підписуйтесь на # - тож як скинути всі повідомлення в базу даних за допомогою Mosquitto?


16

Блоги HiveMQ перелічуються в розділі "Кращі практики", щоб не підписуватися на багаторівневу підстановку при спробі скинути всі повідомлення в базу даних. Вони стверджують, що клієнт, який підписався, може не встигати за великим завантаженням повідомлень, і пропонують використовувати плагін брокера, щоб безпосередньо підключитись до потоку повідомлень.

Іноді доводиться передплачувати всі повідомлення, які передаються через брокера, наприклад, при збереженні всіх їх у базі даних. Цього не слід робити, використовуючи клієнт MQTT та підписавшись на багаторівневу підстановку. Причина полягає в тому, що часто клієнт, який підписався, не в змозі обробити навантаження повідомлень, що надходять на його шляху. Особливо, якщо у вас є велика пропускна здатність. Наше рекомендоване рішення полягає у впровадженні розширення у брокері MQTT, наприклад, плагінова система HiveMQ дозволяє підключитися до поведінки HiveMQ та додати асинхронну процедуру для обробки кожного вхідного повідомлення та збереження його до бази даних.

Чи є і те

  • аналогічна система (розширення / плагін) для брокера комарів,
  • інший рекомендований метод, який працює з комаром, або
  • обґрунтовані докази того, що такий підхід взагалі непотрібний, тобто клієнт, який підписався, #може зробити просто чудово?

/programming//q/31584613/3984613 не вирішує це питання вичерпно.

Відповіді:


12

аналогічна система (розширення / плагін) для брокера комарів

Наскільки я знаю, немає плагіна / розширення для брокера комарів (принаймні, немає жодного відкритого коду)

ще один рекомендований метод, який працює з комаром

Я можу сказати, за моїм досвідом роботи з брокером Mosquitto та AWS IoT, ви можете просто підписатися на "#"

Обґрунтовані докази

Переглянувши це питання, мені було трохи цікаво дізнатися межі пропускної здатності та з’ясувати, чи є необхідність у системі розширення. Тому я встановив наступне:

  • 100 функцій AWS Lambda, які виконують роль віртуальних кінцевих пристроїв для надсилання деяких випадкових даних до шлюзу (екземпляр EC2 t2.nano500 Мб оперативної пам'яті)
  • Кожні 60 секунд функції спрацьовують для публікації даних на шлюзі для різних тем (lambdatoec2 / {VariableTopicNumberFrom1-100}
  • Екземпляр EC2 працює під командою Mosquitto 1.4.10

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


"Правильна" відповідь - тестування. Якщо можна довести, що на продуктивність вашої системи негативно впливає додавання абонента в #, переконфігуруйте брокера, щоб заборонити # підписки. Я відповів на цю відповідь, тому що @bravokeyl зробив саме це.
Джон Детерс

11

Ця дискусія у списку розсилки openHAB, начебто, дозволяє припустити, що немає жодної проблеми з використанням #підписки для отримання всіх повідомлень:

Під час усунення несправностей з пристроями MQTT мені спало на думку, що іноді мені хочеться бачити всі повідомлення MQTT, які бачить брокер Mosquitto, а не певну тему. Чи є спосіб це зробити?

Хтось відповів на це запитання для вас у списку комарів; використовувати підстановку. (#)

Це запитання щодо переповнення стека також пропонує той же метод:

Підписавшись на #, ви підписуєтесь на все, крім тем, які починаються з $ (це як правило, такі теми контролюються).

Краще знати, на що ви спочатку підписуєтесь, звичайно, і зверніть увагу, що деякі конфігурації брокера можуть заборонити підписку на # явно.

Як вказував Бенс Каулікс , у специфікації зазначено, що #це дійсно:

Ненормативний коментар

  • "#" Діє та отримуватиме кожне повідомлення програми

Чесно кажучи, я заперечую, чи справді справжня претензія має взагалі багато сенсу:

Причина полягає в тому, що часто клієнт, який підписався, не в змозі обробити навантаження повідомлень, що надходять на його шляху.

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

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


10

Я думаю, що важливо врахувати, що існує багато різних випадків використання для брокерів MQTT, як і для будь-якого програмного забезпечення.

Обробка повідомлень чату для мільярда користувачів (для багатьох користувачів, відносно низька швидкість повідомлень на користувача) відрізняється від системи з невеликою кількістю клієнтів, але високою швидкістю повідомлення, і вони обидва відрізняються від системи домашньої автоматизації (мало клієнтів, низька швидкість повідомлень) .

HiveMQ замислюються над дуже високими програмами для клієнтів / швидкості повідомлень - у цьому випадку можливості брокера майже напевно значно перевищують можливості клієнта.

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

Як і в інших відповідях, підписка #надасть вам усі "нормальні" теми, тобто все, що не починається з " $. Я трактую специфікацію як те, що кожна тема, що починається з, $- це власне окреме дерево, тож вам доведеться підписатися $SYS/#, $whatever/#щоб отримати все . Ви, швидше за все, не хочете цього робити для звичайного застосування.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.