Серверы и ИИ: практическое применение
Shared subscriptions MQTT и порядок обработки одного устройства
Для ускорения приёма хозяйство добавляет несколько обработчиков в общую подписку. Сообщения начинают распределяться между ними, но прикладная обработка одного устройства может завершаться в ином порядке. Это существенно, если программа хранит состояние, рассчитывает переходы или выбирает последнюю запись по моменту окончания вычисления.
Определить единицу распределения
MQTT5 описывает shared subscription как распределение подходящих публикаций между подписанными сеансами группы. (OASIS — MQTT Version5.0, Standard2019-03-07) Из этого нельзя автоматически получить последовательное завершение пользовательского кода для каждого датчика. Поведение выбора участника и дополнительные гарантии нужно уточнять по установленному брокеру.
Запишите, какие операции потребителя зависят от предыдущего события. Простое независимое сохранение измерения и изменение накопленного состояния имеют разные требования. Для последнего может потребоваться отдельное распределение по ключу устройства или иной подтверждённый механизм сериализации приложения.
Создать проверяемый опыт
Подготовьте собственную последовательность с идентификатором узла и возрастающим номером события. Запустите два учебных обработчика и безопасно увеличьте длительность обработки одного сообщения. Сохраните время получения, начало и конец работы каждого экземпляра. Не ограничивайтесь общим счётчиком успешно прочитанных пакетов.
Проверьте итоговое состояние после завершения всей последовательности. Если поздно закончившаяся старая операция перезаписала более новое значение, проблема находится в контракте обработки, даже когда транспорт доставил все сообщения без видимых ошибок. Этот случай должен иметь заранее определённый ожидаемый результат.
Проверить изменение состава группы
Добавьте и уберите учебного обработчика поддерживаемым способом. Отдельно исследуйте восстановление после остановки участника с незавершённой работой. Не предполагайте одинаковую судьбу сообщений для разных QoS и условий окончания сеанса; используйте фактические правила своей реализации.
Сохраняйте идентичность прикладного события независимо от того, какой обработчик его получил. Это помогает обнаружить повторную обработку и объяснить результат после перераспределения. Короткий идентификатор экземпляра программы не должен становиться идентификатором самого измерения.
Принять масштабирование по смыслу данных
Сравните не только пропускную способность, но и корректность итоговых записей. Если приложение требует порядка, подтвердите его на уровне выбранного механизма, включая перезапуск и изменение числа работников. Общая загрузка процессоров не является доказательством сохранённой последовательности.
В протоколе укажите проверенный состав группы, версии и правила работы с опоздавшим результатом. Тогда увеличение мощности приёмной системы не создаст скрытую перестановку состояний полевого узла, а shared подписка останется осознанным способом распределения нагрузки с понятными прикладными ограничениями.