--- title: "Realtidsdashboards med Laravel, Redis och WebSockets" description: "Så bygger du realtidsdashboards och larm på dataströmmar med stor volym i Laravel: buffrad inläsning, köer, broadcasting, aggregering och dynamiska trösklar." canonical: https://sdk.enterprises/sv/insights/real-time-dashboards-laravel language: sv --- # Realtidsdashboards med Laravel, Redis och WebSockets Uppdaterad: 2026-09-25 > Laravel klarar realtidsdashboards över dataströmmar med stor volym om råa händelser aldrig når webbläsaren: buffra inläsningen i Redis, bearbeta den i köade workers, föraggregera i tidsintervall och sänd bara sammanfattningar över WebSockets. Larma på dynamiska trösklar som lärs in från den senaste historiken i stället för fasta gränser, och lägg till en särskild plattform för dataströmmar när behoven av uppspelning, ordning eller volym växer ur Redis-köerna. ## Håll råa händelser borta från webbläsaren Det vanligaste misstaget i realtidsdashboards är att skicka varje inkommande händelse till varje ansluten skärm. Vid stora volymer halkar webbläsarna efter, WebSocket-servern blir mättad och diagrammet blir ändå oläsligt. Dela upp systemet i fyra steg: inläsning, bearbetning, aggregering och sändning. Varje steg har sin egen kapacitet och kan bli långsammare utan att dra med sig de andra. Dashboarden tar emot aggregerade uppdateringar i en fast takt, till exempel en gång per sekund och panel, inte råa händelser. Våra utvecklare använde den här uppbyggnaden för Slump, en plattform för realtidsövervakning av trender i 5G-nätet, kapacitetsindikatorer och prognoser för mättnad åt operatörer i hela södra Spanien, byggd på en backend i Laravel 11 och 12 som läser in strömmande data i stor volym. ## Buffra inläsningen så att trafiktoppar inte blir avbrott Endpointen för inläsning ska göra så lite som möjligt: validera innehållet, lägga det i en buffert och svara. Tolkning, berikning och skrivningar till databasen hör hemma i workers. Vid måttliga volymer fungerar Redis bra som buffert. Lägg händelserna i en Redis-lista eller Redis-ström och låt workers hämta dem i omgångar, eftersom en samlad insättning är mycket billigare för databasen än hundratals insättningar av enskilda rader. - Validera schemat och avvisa felformaterade händelser redan vid ingången - Svara snabbt och skriv aldrig till den primära databasen inne i anropet - Läs från bufferten i omgångar i stället för en händelse per jobb - Begränsa buffertens längd och larma när den växer, så att mottrycket syns innan det leder till dataförlust ## Skala bearbetningen med separata köer och Horizon Laravels köer med Redis som bas ger dig workers som du kan lägga till horisontellt. Laravel Horizon visar antal workers, genomströmning och väntetider per kö, och det är så du kontrollerar att bearbetningen hänger med inläsningen. Dela upp köerna efter prioritet. Utvärderingen av larm ska aldrig behöva vänta bakom en kö av omräkningar av historiska data, så ge bearbetning, aggregering, larm och exporter egna köer och egna grupper av workers. Gör varje jobb idempotent. Strömmar levererar på nytt, workers kraschar mitt i en omgång och nya försök sker, så att samma händelse bearbetas två gånger får inte dubbla en räknare. En händelseidentifierare som kontrolleras mot en kortlivad Redis-mängd räcker ofta. ## Aggregera i tidsintervall innan du sänder Dashboards visar frekvenser, medelvärden, percentiler och trender, inte enskilda händelser. Beräkna dem i workers i fasta tidsintervall, till exempel per sekund och per minut, för varje enhet du visar: en cell, en region, en kund. Håll de aktuella aggregaten i Redis, med hashar eller sorterade mängder med intervallet som nyckel, och skriv varje avslutat intervall till databasen för historiken. Hur frågorna mot historiktabellerna utformas betyder lika mycket som realtidsflödet, eftersom användarna kommer att zooma ut till en dag eller en vecka. För Slump minskade en ny design av cachningen i Redis och optimering av frågorna latensen vid inläsningen, och det var det som höll realtidsvyn aktuell under belastning. ## Sänd sammanfattningar över WebSockets med Reverb eller en hostad tjänst Laravel broadcasting skickar händelser till kanaler som frontend prenumererar på via Laravel Echo. Laravel Reverb är Laravels egen WebSocket-server, och hostade tjänster som Pusher eller Ably fungerar via samma API för broadcasting. - Sänd med en timer utifrån det aggregerade tillståndet, inte en gång per inkommande händelse - Använd privata kanaler och auktorisera varje prenumeration på servern, så att användarna bara ser de enheter de har rätt att se - Skicka kompakta ögonblicksbilder eller ändringar, inte hela datamängder - Vid återanslutning: låt klienten hämta det aktuella tillståndet via HTTP och sedan återuppta strömmen - Kör flera Reverb-instanser bakom en lastbalanserare, med Redis pub/sub mellan dem, när antalet anslutningar växer ## Larma på dynamiska trösklar i stället för fasta gränser Fasta trösklar slår fel åt båda hållen på strömmande mätvärden. Trafiken klockan 03 ser inte alls ut som trafiken klockan 20, så en enda gräns larmar antingen hela natten eller missar problem dagtid. En dynamisk tröskel jämför varje nytt värde med ett utgångsvärde som lärs in från den senaste historiken för samma enhet och samma tid i veckan. En enkel version som går att förklara håller ett rullande medelvärde och en standardavvikelse per enhet och timme i veckan, och larmar när värdet ligger utanför det bandet under flera intervall i rad. För Slump minskade dynamiska larm om avvikelser den manuella övervakningen, eftersom operatörerna larmades vid verkliga avvikelser i stället för att bevaka skärmar. - Kräv att avvikelsen består, till exempel tre intervall i rad utanför bandet, för att minska bruset - Håll ett öppet larm per enhet och villkor, som uppdateras i stället för att upprepas - Ta med aktuellt värde, utgångsvärde, band och en länk till panelen i varje larm - Gå regelbundet igenom tystade och ignorerade larm och justera bandet ## Vet när det är dags för en särskild strömningsplattform Laravel med Redis täcker mycket, men har sina gränser. Överväg Kafka, Redpanda eller en hanterad strömningstjänst, ofta med en strömprocessor som Apache Flink, när du behöver lång lagring och uppspelning av råa händelser, strikt ordning per nyckel över många konsumenter eller en genomströmning som gör Redis minne till flaskhalsen. Bytet behöver inte ske på en gång. Behåll Laravel för API:et, dashboards, larmhantering och broadcasting, och lägg strömmen före aggregeringssteget. Vi bygger och vidareutvecklar realtidssystem med den här uppbyggnaden, från inläsningen till de larmregler som operatörerna förlitar sig på. ## Det viktigaste - Strömma aldrig råa händelser till webbläsare; sänd aggregerade sammanfattningar i en fast takt. - Håll endpointen för inläsning tunn och buffra händelser i Redis för bearbetning i omgångar av workers. - Dela upp köer efter prioritet och gör varje jobb idempotent så att nya försök inte kan förstöra räknare. - Dynamiska trösklar baserade på den senaste historiken ger färre och mer användbara larm än fasta gränser. - Lägg till Kafka eller en liknande plattform när du behöver uppspelning, strikt ordning eller volymer bortom Redis, och behåll Laravel för applikationslagret. ## Vanliga frågor ### Klarar Laravel realtidsdashboards för data i stor volym? Ja, när arkitekturen håller det tunga arbetet borta från anropsflödet: en tunn endpoint för inläsning, en buffert i Redis, köade workers som aggregerar i tidsintervall och WebSocket-sändningar av enbart sammanfattningar. Laravel sköter då API:et, dashboards och larm medan workers skalas oberoende. ### Ska jag använda Laravel Reverb eller Pusher för WebSockets? Reverb är Laravels egen WebSocket-server och körs på din egen infrastruktur, vilket passar team som vill ha kontroll över kostnader och var data finns. Pusher eller Ably tar bort driftarbetet med att köra WebSocket-servrar. Båda använder samma API för broadcasting i Laravel, så du kan byta senare. ### Vad är en dynamisk tröskel i övervakning? En dynamisk tröskel är en larmgräns som beräknas från den senaste historiken för samma mätvärde, samma enhet och samma tid i veckan, i stället för ett fast tal. Den anpassar sig efter mönster över dygnet och veckan, så att larmen går vid verkliga avvikelser i stället för vid normala toppar. ## Relaterade tjänster - [Skräddarsydd mjukvara](https://sdk.enterprises/sv/services/product-engineering)