Кластер, дашборд, вес: чем EMQX оправдывает уход с Mosquitto

MAATRIX

Mosquitto держит десяток датчиков и Zigbee2MQTT без единой жалобы, но стоит проекту вырасти — появиться нескольким площадкам, распределённым воркерам, требованию не терять сообщения при перезапуске брокера — и начинаешь читать про EMQX: кластер, встроенный веб-дашборд, движок правил без единой строчки кода. Вопрос не в том, какой брокер «лучше» — оба реализуют MQTT 5.0 и справляются с базовой публикацией/подпиской одинаково честно. Вопрос в том, за что вы платите памятью и сложностью конфигурации, когда меняете один на другой, и оправдывает ли это ваш конкретный масштаб. Разберём по цифрам и сценариям, а не по маркетинговым слайдам.

Что вообще разное: архитектура, а не протокол

Mosquitto — это Eclipse-проект на C, брокер, который делает ровно одну вещь: принимает MQTT-соединения, публикует и рассылает сообщения по подпискам, умеет ACL, TLS, persistence сообщений на диск и мосты (bridge) между несколькими инстансами. Весь брокер — один процесс, один конфиг-файл в текстовом формате, никакой веб-панели из коробки. Хотите посмотреть, кто подключён и что публикуется — подписывайтесь mosquitto_sub на $SYS/# или ставьте отдельный инструмент вроде MQTT Explorer.

EMQX — брокер на Erlang/OTP, написанный поверх модели акторов и механизмов отказоустойчивости, которые Erlang десятилетиями обкатывал в телекоме. Это не просто «Mosquitto с панелью» — под капотом другая архитектура кластера: узлы EMQX реплицируют таблицу маршрутизации между собой через Mria (форк Mnesia с оптимизацией под MQTT), и клиент на одном узле получает сообщения от издателя на другом узле без ручной настройки мостов. Из коробки: веб-дашборд с графиками подключений и трафика, движок правил (rule engine) для маршрутизации сообщений во внешние системы без написания кода, поддержка MQTT over QUIC, плагины интеграции с Kafka, PostgreSQL, MySQL, Redis, вебхуками.

Формально оба брокера — MQTT-серверы. По факту это разный класс инструмента: Mosquitto — компактный демон для одного узла, EMQX — платформа для управления парком клиентов с горизонтальным масштабированием. Сравнивать их по фиче-листу малополезно — вопрос в том, нужен ли вам весь этот платформенный слой прямо сейчас.

Кластеризация: когда один узел реально мало

Mosquitto кластера в открытой версии не имеет вовсе — только bridge, то есть пересылку топиков между двумя независимыми брокерами. Это работает для интеграции разных площадок («пересылать показания с датчиков филиала на центральный брокер»), но не даёт единого пространства подписок: клиент на брокере А не увидит напрямую сообщение, опубликованное на брокере Б, если топик не прописан в мосте явно. Отказоустойчивости в привычном смысле — «упал один узел, клиенты сами переключились на другой без потери сессии» — Mosquitto из коробки не даёт. Есть коммерческая версия Mosquitto (от Cedalo) с кластеризацией, но open source ограничивается мостами.

EMQX кластеризуется нативно: несколько узлов образуют единый логический брокер, таблица маршрутизации реплицируется между ними, и клиент может переподключиться к любому живому узлу за DNS-именем кластера или через балансировщик — сессия (с флагом clean_start: false) восстановится, если период Session Expiry Interval ещё не истёк. Node discovery настраивается через статический список узлов, DNS SRV-записи, etcd или Kubernetes API — в emqx.conf:

cluster {
  name = emqxcl
  discovery_strategy = static
  static.seeds = ["emqx@10.0.0.1", "emqx@10.0.0.2", "emqx@10.0.0.3"]
}

Практический порог, когда кластер начинает окупать сложность настройки, — это не число сообщений в секунду (оба брокера справляются с умеренным потоком на одном ядре без напряжения), а требование к доступности и география клиентов. Если у вас один сервер, один регион, и простой в пару минут на обновление брокера не критичен — кластер решает проблему, которой у вас нет. Если клиенты подключаются из нескольких дата-центров, или платформа завязана на SLA с обязательством не терять входящие сообщения при падении одной ноды, — кластер снимает реальный риск, а не добавляет технической красоты ради неё самой.

Отдельно стоит понимать: кластер EMQX — это не бесплатная отказоустойчивость. Три узла требуют трёх серверов (или минимум трёх виртуалок, но тогда падение хост-машины валит всех разом), сетевой связности между ними с низкой задержкой (Mria чувствителен к сетевым разрывам между узлами — split-brain разруливается, но не мгновенно и не без нюансов), и мониторинга самого кластера, а не только брокера. Для домашнего проекта с одним VPS это не имеет смысла: кластер из одного узла — просто более тяжёлый Mosquitto.

Дашборд: экономит часы диагностики, но не бесплатен

Веб-дашборд EMQX (по умолчанию на порту 18083) показывает список подключённых клиентов с их IP, версией протокола, качеством обслуживания подписок, живой график входящих/исходящих сообщений, состояние кластера по узлам, список активных правил, и позволяет вручную опубликовать сообщение в топик или отключить клиента без перезапуска брокера. Для отладки — это разница между «читать логи и гадать» и «увидеть проблему за десять секунд»: сразу видно, отключился ли датчик, подключён, но не публикует, или публикует в неправильный топик.

В Mosquitto эквивалент собирается вручную: mosquitto_sub -t '$SYS/#' -v даёт текстовые метрики (число клиентов, сообщений, байт), а визуализацию нужно строить самому — экспортировать $SYS-топики через mqtt-exporter в Prometheus и рисовать графики в Grafana. Если у вас уже есть Prometheus и Grafana под другие сервисы, добавить туда MQTT-метрики — час работы, и это честная альтернатива, а не тупик; подробности связки разобраны в статье про Prometheus и Grafana.

Обратная сторона дашборда EMQX — это самостоятельный веб-сервис внутри брокера: свой HTTP-порт, своя аутентификация (по умолчанию admin/public, обязательно смените при первом входе), свой TLS-сертификат, если открываете его наружу, и это дополнительная поверхность атаки, которую нужно закрывать firewall'ом или VPN, а не выставлять в интернет напрямую. Для проекта с парой десятков устройств тратить время на защиту веб-панели ради удобства просмотра пяти клиентов — не всегда выгодный обмен.

Правила обработки сообщений: движок без кода против скриптов снаружи

Rule Engine EMQX — это, пожалуй, самая недооценённая часть платформы за пределами кластеризации. Правило — это SQL-подобный запрос к потоку сообщений с действием на выходе:

SELECT
  payload.temperature as temp,
  clientid,
  topic
FROM
  "sensor/+/telemetry"
WHERE
  payload.temperature > 30

К правилу привязывается действие (action): отправить вебхук, записать в PostgreSQL/MySQL/ClickHouse, переслать в Kafka, republish в другой топик с трансформацией payload. То есть логика «если температура выше порога — записать в базу и дёрнуть вебхук» настраивается через веб-интерфейс или конфиг, без написания отдельного сервиса-подписчика на Python или Node-RED.

В экосистеме Mosquitto эквивалентная логика реализуется снаружи брокера: пишете отдельный процесс (скрипт на Python с paho-mqtt, или связку Node-RED), который подписывается на нужные топики и обрабатывает сообщения сам. Это гибче в смысле языка программирования, но требует держать отдельный процесс и следить за его падениями — ещё один компонент в цепочке отказа. Для многих домашних проектов Node-RED уже стоит рядом с Zigbee2MQTT и Home Assistant ради автоматизаций, и тогда Rule Engine EMQX не даёт качественного выигрыша — вы просто переносите ту же логику из одного визуального редактора в другой.

Rule Engine оправдывает себя там, где нужна прямая интеграция с внешней БД или очередью без промежуточного сервиса-подписчика: например, писать телеметрию сразу в PostgreSQL для последующей аналитики, или переливать поток в Kafka для дальнейшей обработки в системе, которая уже стоит в инфраструктуре. Если вся ваша обработка — это Home Assistant, слушающий тот же MQTT, отдельный движок правил просто дублирует то, что Home Assistant уже делает через автоматизации.

Вес: сколько памяти и CPU реально добавляет переход

Это раздел, где ориентиры важнее абсолютных цифр — конкретное потребление зависит от числа клиентов, частоты сообщений, размера retained-сообщений и включённых плагинов, поэтому воспринимайте цифры ниже как порядок величины, а не гарантию.

Mosquitto в состоянии покоя с несколькими клиентами держит около 10-30 МБ RAM — это уже подтверждено на практике для связки с Zigbee2MQTT и Home Assistant, где Mosquitto стабильно остаётся самым лёгким компонентом стека. Рост потребления с числом сообщений в секунду минимальный, потому что брокер не хранит историю — только текущие подписки и retained-значения.

EMQX — это Erlang VM с собственным рантаймом, и старт даже одного узла ощутимо тяжелее: свежий инстанс EMQX Open Source в контейнере занимает по памяти на порядок больше, чем Mosquitto в покое — ориентировочно от 150-250 МБ уже без единого подключённого клиента, просто за счёт инициализации Erlang VM, дашборда, Mria и служебных процессов. Дальнейший рост с числом клиентов идёт мягче, чем стартовый порог, но сама база выше на порядок с самого начала. Под кластер из трёх узлов закладывайте по серверу на каждый — суммарный бюджет памяти легко переваливает за 1-1.5 ГБ только на сам брокер, без учёта соседних сервисов.

Таблица для ориентира на VPS (single-node, без учёта соседних контейнеров):

CPU у обоих брокеров в простое почти не расходуется — разница проявляется на пиках подключений (реконнект после сетевого сбоя у сотен клиентов разом) и на активном использовании Rule Engine, где каждое совпадающее сообщение прогоняется через SQL-движок — это заметно дороже по CPU, чем прямая доставка сообщения подписчику в Mosquitto.

Для голого сравнения памяти при выборе VPS полезно свериться со статьёй сколько RAM нужно для Zigbee2MQTT — там разобран стек, где Mosquitto стоит рядом с Home Assistant, и разница в весе самого брокера особенно наглядна на фоне более тяжёлых соседей.

Docker Compose: минимальный запуск обоих

Для честного сравнения — минимальные конфигурации без лишних опций. Mosquitto:

services:
  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mosquitto
    restart: unless-stopped
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
      - ./mosquitto/log:/mosquitto/log
    deploy:
      resources:
        limits:
          memory: 128M

EMQX:

services:
  emqx:
    image: emqx/emqx:5.8
    container_name: emqx
    restart: unless-stopped
    ports:
      - "1883:1883"
      - "8083:8083"
      - "18083:18083"
    environment:
      - EMQX_NAME=emqx
      - EMQX_HOST=127.0.0.1
    volumes:
      - emqx-data:/opt/emqx/data
      - emqx-log:/opt/emqx/log
    deploy:
      resources:
        limits:
          memory: 512M

volumes:
  emqx-data:
  emqx-log:

Порт 18083 — это дашборд, 8083 — MQTT over WebSocket, 1883 — обычный MQTT TCP. Обратите внимание на лимит памяти: 512 МБ — комфортный минимум для одного узла EMQX с несколькими десятками клиентов, и это уже в 4-8 раз больше, чем закладывается под Mosquitto для того же числа устройств.

Для кластера каждый узел EMQX запускается как отдельный сервис (или на отдельном хосте) с одинаковым EMQX_CLUSTER__DISCOVERY_STRATEGY и списком seed-узлов в переменных окружения — здесь docker-compose на одном хосте уже не отражает реальный кейс кластера, потому что смысл кластера в устойчивости к падению целого сервера, а не контейнера на нём же.

Миграция и когда не стоит вообще трогать Mosquitto

Если Mosquitto у вас работает без нареканий — держит нужное число клиентов, не падает, ACL и TLS настроены, — миграция на EMQX ради самого факта миграции не решает никакой проблемы, только добавляет вес и площадь конфигурации. Признак, что пора смотреть в сторону EMQX: вы уже испытываете конкретную боль, которую Mosquitto структурно не решает — нужна отказоустойчивость на уровне брокера, интеграция телеметрии напрямую в БД или очередь без отдельного сервиса, или растёт число подключений настолько, что нужна видимость по каждому клиенту без сборки собственного мониторинга.

Технически перенос клиентов простой: и Mosquitto, и EMQX говорят на MQTT 3.1.1 и 5.0, поэтому у клиентских приложений (Zigbee2MQTT, Home Assistant, свои скрипты) меняется только адрес брокера и, если было настроено, — сертификаты TLS и учётные записи. ACL придётся переносить вручную: у Mosquitto это плоский файл acl, у EMQX — правила через веб-интерфейс, конфиг или базу, прямого конвертера между форматами нет. Persistent-сессии и retained-сообщения автоматически не переносятся — если это критично, переключайте клиентов в окно, когда потеря части истории допустима, или временно держите оба брокера на связи через bridge.

Практичный план для тех, кто хочет попробовать EMQX не рискуя продакшеном: поднять его рядом с уже работающим Mosquitto на отдельном сервере, замостить (bridge) нужные топики в обе стороны, перевести часть некритичных клиентов и понаблюдать неделю-две за памятью и стабильностью, прежде чем переключать основной поток устройств — так вы оцените реальный вес под свой трафик, не трогая уже работающую связку.

Частые вопросы