Архитектурный план: аналитика с низкой задержкой для площадок
Управление данными 20 000 человек на живом мероприятии — это не то же самое, что разработка веб-приложения.
В веб-приложениях пользователи распределены по часовым поясам. На крупных площадках тысячи людей создают мощные всплески данных одновременно. Утренний час пик может перегрузить стандартную систему.
Если вы используете пакетную обработку или long-polling, данные приходят с опозданием. В управлении толпой задержка в 15 минут — это провал. Вы заметите затор в толпе только после того, как он уже случится.
Вам нужны обновления менее чем за секунду. Необходимо построить конвейер потоковой передачи данных от периферии (edge) до вашего дашборда.
Вот архитектура, которая вам необходима:
- Периферийный уровень (Ingestion) Установите промышленный edge-узел на каждом входе. Подключите его к RFID-считывателям через последовательную шину.
Не полагайтесь на облако для принятия мгновенных решений. Используйте локальную базу данных в оперативной памяти, такую как Redis, на edge-узле. Это позволит системе проверять разрешения менее чем за 5 мс. Если интернет на площадке пропадет, турникеты продолжат работать.
- Транспортный уровень (MQTT) Перестаньте использовать HTTP REST-эндпоинты для периферийного оборудования. HTTP создает слишком большие накладные расходы для тысяч мелких сканирований.
Вместо этого используйте MQTT. Он использует минимальный размер пакета и поддерживает постоянное соединение. Это работает даже в нестабильных сетях площадки. Edge-узлы отправляют сжатые данные на облачный брокер. Брокер мгновенно перенаправляет эти события вашим воркерам.
- Визуальный уровень (WebSockets) Вашей операционной группе нужно видеть изменения по мере их возникновения. Не заставляйте браузер запрашивать обновления через API.
Используйте WebSockets для полнодуплексного соединения. Это позволяет мгновенно передавать данные на дашборд. Когда зал переполняется, команда видит это менее чем за секунду. После этого они могут перераспределить персонал или обновить цифровые указатели, чтобы наладить поток людей.
Итог стека:
- Edge: локальный Redis + промышленный ПК
- Transport: MQTT (EMQX или HiveMQ)
- Frontend: WebSockets для UI в реальном времени
Как вы обрабатываете данные о плотных скоплениях людей в своих IoT-системах? Давайте обсудим инфраструктуру ниже.