Projektowanie analityki zdarzeń o niskich opóźnieniach
Budowanie potoków danych dla dużych obiektów fizycznych jest trudne.
Wydarzenie na 20 000 osób generuje inne problemy niż standardowa aplikacja webowa. W aplikacji webowej użytkownicy są rozproszeni w różnych strefach czasowych. W obiekcie tysiące osób generuje skoki danych w tym samym czasie.
Przetwarzanie wsadowe lub long-polling spowodują opóźnienia. W zarządzaniu tłumem 15-minutowe opóźnienie to porażka. W efekcie reagujesz na stare problemy, zamiast im zapobiegać.
Aby uzyskać prędkość poniżej sekundy, potrzebujesz ciągłego strumienia danych z urządzeń brzegowych (edge hardware) do swojego pulpitu nawigacyjnego.
Oto schemat odpornego potoku telemetrii.
Warstwa 1: Edge Compute w modelu Offline-First
Potrzebujesz opóźnień poniżej 5 ms. Musisz również radzić sobie z przerwami w łączności sieciowej. Użyj węzłów brzegowych (edge nodes) z lokalnym cache'em w pamięci, takim jak Redis. Przed rozpoczęciem wydarzenia zsynchronizuj swoją bazę danych w chmurze z tymi węzłami.
Gdy uczestnik skanuje tag, system sprawdza lokalny cache. Pozwala to ominąć internet i zapewnia płynny ruch przy bramkach.
Warstwa 2: Asynchroniczne wprowadzanie danych (ingestion) przez MQTT
Sieci w obiektach są często niestabilne. Użyj MQTT, ponieważ jest lekkim protokołem. Węzły brzegowe publikują wiadomości do brokera w chmurze, który następnie przekierowuje dane do kolejek wprowadzania danych (ingestion queues).
Warstwa 3: Full-Duplex WebSockets
Nie sprawiaj, aby frontend odpytywał o aktualizacje. Użyj WebSocketów, aby utrzymać stałe połączenie z bramą API (API gateway). Dzięki temu zespół operacyjny zobaczy zmiany na hali w czasie krótszym niż sekunda.
Taka konfiguracja pozwala zespołom natychmiast wykrywać nagłe przyrosty tłumu lub niski poziom zaangażowania. Możesz przekierować personel, zanim powstanie zator.
Jak optymalizujesz sprzęt IoT dla gęstych tłumów? Podziel się swoimi przemyśleniami poniżej.