MQTT брокеры: Mosquitto и EMQX - настройка для IoT проектов
окт, 27 2026
Представьте ситуацию: у вас есть тысяча датчиков температуры на складе. Каждый из них шлет данные каждые пять секунд. Если вы попытаетесь обрабатывать это через HTTP-запросы, ваш сервер задохнется от нагрузки еще до обеда. Именно здесь на сцену выходит MQTT - легковесный протокол обмена сообщениями, который стал стандартом де-факто для интернета вещей. Но сам по себе протокол бесполезен без «почтальона», который доставляет письма. Этим почтальоном выступает MQTT брокер.
В мире открытого ПО два гиганта делят рынок бесплатных решений: Mosquitto и EMQX. Первый - классика жанра, простой как топор, второй - современный монстр масштабируемости. Как выбрать? И главное, как их настроить так, чтобы не сойти с ума в логах? Разберем всё по полочкам.
Почему выбор брокера решает судьбу проекта
Многие новички думают: «MQTT есть MQTT, какая разница, где крутить». Это ошибка. Брокер - это центральная нервная система вашей IoT архитектуры. Он принимает публикации (publish) от устройств и рассылает подписчикам (subscribe). Если брокер ляжет, вся автоматизация встанет. Если он будет тормозить, вы получите лаги в реальном времени.
Здесь важно понимать разницу в философии двух лидеров. Eclipse Mosquitto создан для минимализма. Он написан на C, занимает копейки оперативной памяти и идеально подходит для Raspberry Pi или слабых VPS. Его задача - просто передать сообщение. Никаких лишних украшений.
EMQX, напротив, позиционируется как платформа для сверхмасштабных подключений. Написанный на Erlang/OTP, он спроектирован для обработки миллионов одновременных соединений. В версии 5.x разработчики добавили поддержку SQL-подобных запросов внутри правил маршрутизации сообщений. Это уже не просто брокер, а полноценная middleware-платформа.
Mosquitto: быстрый старт для небольших систем
Если у вас домашняя умная колонка или стартап с десятками датчиков, начинайте с Mosquitto. Установка тривиальна даже для тех, кто далек от Linux.
На Ubuntu/Debian команда одна:
sudo apt update
sudo apt install mosquitto mosquitto-clients
Сервис сразу запускается и слушает порт 1883 (нешифрованный) или 8883 (TLS). Но по умолчанию конфигурация может быть слишком закрытой или наоборот, открытой для всех подряд. Давайте настроим безопасность.
Откройте файл /etc/mosquitto/conf.d/default.conf. Нам нужно создать пользователя и ограничить доступ. Без пароля в продакшене делать нечего - любой сканер портов найдет ваш брокер и начнет слать мусор.
# Пример конфига
listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd
log_dest file /var/log/mosquitto/mosquitto.log
Теперь создадим пользователя командой mosquitto_passwd -c /etc/mosquitto/passwd admin. После этого перезапустите сервис: systemctl restart mosquitto.
Как проверить работу? Используйте клиентскую утилиту. В одном терминале подпишитесь на топик:
mosquitto_sub -h localhost -t "test/topic" -u admin -P password
В другом опубликуйте сообщение:
mosquitto_pub -h localhost -t "test/topic" -m "Hello World" -u admin -P password
Если текст появился в первом окне - поздравляю, ваш первый MQTT канал работает. Простота Mosquitto - его главная сила. Нет лишней логики, нет сложных зависимостей. Если что-то ломается, причина обычно кроется в сетевых настройках или правах доступа к файлам логов.
EMQX: когда нужно больше мощи
Допустим, ваш проект вырос. Теперь вам нужно подключить 50 тысяч промышленных контроллеров. Mosquitto на одном ядре CPU начнет задыхаться при высокой частоте публикаций. Тут на помощь приходит EMQX. Его установка чуть сложнее, но результат того стоит.
Самый простой способ установки - через Docker. Это изолирует среду и упрощает обновления.
docker run -d --name emqx \
-p 1883:1883 \
-p 8083:8083 \
-p 18083:18083 \
-v $(pwd)/data:/opt/emqx/data \
emqx/emqx:latest
Обратите внимание на порты. 1883 - стандартный MQTT. 8083 - WebSocket (для браузеров). А вот 18083 - это веб-интерфейс управления. Зайдите в браузере на http://localhost:18083. Логин по умолчанию: admin/public. Интерфейс красив, информативен и показывает графики нагрузки в реальном времени.
Главное преимущество EMQX - встроенные правила (Rules Engine). Вам не нужно писать отдельный микросервис на Python, чтобы пересылать данные из MQTT в базу данных PostgreSQL. Вы можете написать SQL-запрос прямо в интерфейсе:
SELECT * FROM "t/#" WHERE payload.temperature > 25
Этот код фильтрует все сообщения из топиков, начинающихся с "t/", и оставляет только те, где температура выше 25 градусов. Затем эти данные можно отправить в Kafka, RabbitMQ или напрямую в базу. Для Mosquitto такое поведение потребует написания внешнего скрипта-моста.
Сравнение возможностей: таблица выбора
Чтобы не гадать, давайте посмотрим на сухие цифры и возможности. Эта таблица поможет принять решение, если вы на распутье.
| Критерий | Eclipse Mosquitto | EMQX |
|---|---|---|
| Язык программирования | C | Erlang/OTP |
| Потребление RAM (idle) | < 10 МБ | ~ 100-200 МБ |
| Максимум соединений (single node) | ~ 10-50 тыс. | ~ 1 млн+ |
| Веб-интерфейс управления | Нет (нужны сторонние панели) | Да, встроенный Dashboard |
| Кластеризация | Сложная (через bridge) | Нативная, простая настройка |
| Логика обработки сообщений | Минимальная (ACL) | SQL Rules Engine, Webhooks |
| Лицензия | EPL/Eclipse Foundation | Apache 2.0 (Open Source) |
Как видите, разница колоссальная. Mosquitto выигрывает там, где ресурсы ограничены. EMQX побеждает там, где нужна бизнес-логика внутри брокера.
Типичные ошибки при настройке
Даже опытные админы иногда попадают в ловушки. Вот три самых частых грабли, на которые наступают пользователи обоих брокеров.
- Проблемы с TLS сертификатами. Многие игнорируют шифрование, оставляя порт 1883 открытым наружу. Хакеры обожают MQTT, потому что легко могут подделать идентификатор клиента (ClientID) и перехватить команды управления. Всегда используйте 8883 порт с валидными сертификатами Let's Encrypt.
- Неверная настройка KeepAlive. По умолчанию клиенты часто используют интервал 60 секунд. Если сеть нестабильная, соединение может разорваться раньше, чем придет пинг. Уменьшите значение до 15-30 секунд для мобильных устройств, но следите за трафиком.
- Игнорирование QoS уровней. MQTT имеет три уровня гарантии доставки (QoS 0, 1, 2). Новички ставят везде QoS 0 («выстрелил и забыл») ради скорости. Но для критических команд (например, «выключить клапан газа») нужен QoS 1 или 2. Mosquitto плохо справляется с хранением очередей QoS 1 при отключении клиента, если не настроена persistent session правильно. EMQX делает это «из коробки» лучше.
Интеграция с экосистемой Home Assistant и Node-RED
Если вы читаете эту статью, скорее всего, вы собираете свою систему умного дома или промышленный мониторинг. Оба брокера отлично дружат с популярными инструментами.
Home Assistant умеет работать с любым MQTT брокером. Для Mosquitto интеграция нативная: вы просто указываете IP и логин в YAML конфиге. Для EMQX процесс идентичен, но вы получаете возможность использовать сложные темы (topics) с wildcards (+ и #), которые EMQX обрабатывает эффективнее.
Node-RED - визуальный редактор потоков данных. Здесь оба брокера показывают себя хорошо. Однако с EMQX вы можете реализовать более сложную логику предобработки данных до попадания в Node-RED. Например, агрегировать показания десяти датчиков в одно сообщение прямо на уровне брокера, снижая нагрузку на поток Node-RED.
Для тестирования связей удобно использовать утилиту MQTTX - графический клиент, который позволяет визуально публиковать и подписываться на топики, проверяя связность между устройствами и брокером без написания кода.
Когда переходить с Mosquitto на EMQX?
Не меняйте брокер просто так. Переход требует времени и тестов. Делайте это, если:
- У вас более 10 000 активных клиентов одновременно.
- Вы нуждаетесь в кластеризации для отказоустойчивости (если один узел упадет, остальные подхватят).
- Вам нужно интегрировать MQTT с реляционными базами данных без написания промежуточного кода.
- Вы используете WebSocket соединения для веб-приложений в больших объемах.
Если же у вас домашний сервер на Raspberry Pi 4 с 4 ГБ памяти и 50 датчиков Zigbee, оставьте Mosquitto. Он стабильнее в простых условиях и требует меньше внимания. Не усложняйте архитектуру там, где она должна оставаться простой.
Какой порт использовать для безопасного подключения MQTT?
Стандартный незащищенный порт - 1883. Для защищенного соединения через TLS/SSL используйте порт 8883. Также часто применяется порт 8083 для WebSocket (незащищенный) и 8084 для WebSocket Secure. Всегда рекомендуется использовать TLS в продакшене, чтобы предотвратить перехват данных.
Можно ли использовать Mosquitto и EMQX одновременно?
Технически да, они могут работать на разных портах одного сервера или разных машинах. Но логически это редко имеет смысл, так как они выполняют одну и ту же функцию. Обычно выбирают один основной брокер. Исключение - миграция данных или разделение окружений (dev/prod).
Как обеспечить высокую доступность (High Availability) для MQTT?
Mosquitto не поддерживает нативную кластеризацию «из коробки» для балансировки нагрузки между клиентами. Часто используют HAProxy перед несколькими инстансами Mosquitto с синхронизацией через bridges. EMQX имеет встроенную поддержку кластеров Erlang, что позволяет автоматически распределять клиентов между узлами и реплицировать состояние сессий.
Что такое Retained Messages и зачем они нужны?
Retained message - это последнее опубликованное сообщение в топике, которое брокер сохраняет в памяти. Когда новый клиент подписывается на этот топик, он мгновенно получает это сохраненное сообщение, даже если оно было отправлено давно. Это полезно для передачи текущего состояния устройства (например, текущая температура) новым подписчикам.
Есть ли ограничения по количеству топиков в бесплатных версиях?
В open-source версиях Mosquitto и EMQX жестких программных ограничений на количество уникальных топиков нет, они зависят от объема оперативной памяти сервера. Однако в коммерческих облачных решениях провайдеров могут быть лимиты. Для локального развертывания упор делается на производительность CPU и RAM.