Коротко о главном
Для MQTT-шлюза нужно явно решить, какие данные сохраняются при потере связи. История измерений, текущее состояние и команда управления имеют разные требования. Сам факт повторного подключения не подтверждает правильное продолжение работы приложения.
Разделите сообщения по назначению
Для каждого типа определите, достаточно ли последнего состояния или необходим полный журнал. Укажите, когда информация устаревает. Старое измерение может быть полезно для истории, но непригодно для отображения текущего состояния оборудования.
Назначьте идентификаторы устройства и события. Опишите, относится ли время к измерению или к отправке. Если после перезапуска часы ещё недостоверны, эта неопределённость должна быть видна получателю, а не превращаться в правдоподобную, но ошибочную дату.
Не путайте возможности протокола с буфером приложения
MQTT 5 различает срок существования сессии и срок жизни сообщения. Эти параметры не создают автоматически постоянное локальное хранилище приложения. OASIS — MQTT Version 5.0
Отдельно опишите, что сохраняют устройство, библиотека, брокер и получатель. Проверьте используемую реализацию и настройки. Недокументированное значение по умолчанию не является обоснованной гарантией поведения после перезапуска устройства или обновления программной библиотеки.
Рассчитайте объём и поведение при переполнении
Начальная оценка: частота сообщений × максимальное время без связи × размер сохранённой записи. Добавьте служебные данные и резерв. Например, две записи в секунду за час дают 7 200 записей; их объём ещё зависит от формата каждой записи.
Выберите действие при заполнении: заменить старые данные, отбрасывать выбранные сообщения или сообщать об ошибке. Ограничьте скорость отправки накопленного, чтобы новые измерения и управление продолжали обслуживаться. Для постоянной памяти учитывайте предполагаемую частоту записи.
Испытывайте результат всей цепочки
Получатель должен по прикладному идентификатору распознавать уже обработанное событие. Повторное сообщение не должно случайно выполнить команду ещё раз. Для команд отдельно определите срок действия и подтверждение результата.
Раздельно испытайте потерю сети, перезапуск брокера и устройства. После восстановления проверьте количество, порядок, возраст и повторную обработку данных. Успех — это ожидаемое поведение приложения, а не только зелёный индикатор соединения или запись о подключении.
Решения для автономного режима
- Разделить историю, состояние и команды.
- Задать допустимый возраст и время без связи.
- Рассчитать буфер и правило переполнения.
- Определить идентификаторы и обработку повторов.
- Раздельно проверить отказ сети, брокера и устройства.
Частые вопросы
Высокий QoS гарантирует однократное выполнение операции?
Сам по себе нет. Приложение должно определить связь получения, сохранения и обработки, а также распознавание повторных событий.
Нужно ли постоянно хранить каждое измерение?
Только если этого требует задача. Для части индикаторов достаточно последнего состояния, а для истории пропуски могут быть существенны. Решение должно быть записано в требованиях.
Технические источники
Услуга по теме