--- title: "Sanntidsdashbord med Laravel, Redis og WebSockets" description: "Slik bygger du sanntidsdashbord og varsler på datastrømmer med høyt volum i Laravel: bufret inntak, køer, kringkasting, aggregering og dynamiske terskler." canonical: https://sdk.enterprises/no/insights/real-time-dashboards-laravel language: no --- # Sanntidsdashbord med Laravel, Redis og WebSockets Oppdatert: 2026-09-25 > Laravel kan drive sanntidsdashbord over datastrømmer med høyt volum hvis rå hendelser aldri når nettleseren: bufre inntaket i Redis, behandle det i workere via køer, forhåndsaggreger i tidsintervaller og send bare sammendrag over WebSockets. Varsle på dynamiske terskler lært fra nylig historikk i stedet for faste grenser, og legg til en egen strømmeplattform når behovet for avspilling, rekkefølge eller volum vokser ut over Redis-køer. ## Hold rå hendelser unna nettleseren Den vanligste feilen i sanntidsdashbord er å sende hver innkommende hendelse til hver tilkoblede skjerm. Ved høyt volum henger nettleserne etter, WebSocket-serveren blir mettet, og grafen blir uansett uleselig. Del systemet inn i fire trinn: inntak, behandling, aggregering og kringkasting (broadcasting). Hvert trinn har sin egen kapasitet og kan gå saktere uten å dra de andre med seg. Dashbordet mottar aggregerte oppdateringer i et fast tempo, for eksempel én gang i sekundet per panel, ikke rå hendelser. Utviklerne våre brukte denne strukturen på Slump, en plattform for sanntidsovervåking av trender i 5G-nettet, kapasitetsindikatorer og prediksjon av metning for operatører i hele Sør-Spania, bygget på en backend i Laravel 11 og 12 som tar inn strømmedata med høyt volum. ## Bufre inntaket, slik at trafikktopper ikke blir til driftsstans Endepunktet for inntak bør gjøre så lite som mulig: validere nyttelasten, legge den til i en buffer og returnere. Parsing, beriking og skriving til databasen hører hjemme i workere. Ved moderat volum fungerer Redis godt som denne bufferen. Legg hendelsene i en Redis-liste eller -strøm, og la workerne hente dem i bolker, fordi én samlet innsetting er langt billigere for databasen enn hundrevis av innsettinger med én rad hver. - Valider skjemaet og avvis feilformaterte hendelser allerede ved inngangen - Returner raskt, og skriv aldri til hoveddatabasen inne i forespørselen - Les fra bufferen i bolker i stedet for én hendelse per jobb - Sett et tak på lengden av bufferen og varsle når den vokser, slik at mottrykket blir synlig før det fører til tap av data ## Skaler behandlingen med separate køer og Horizon Laravel-køer med Redis i bunnen gir deg workere du kan legge til horisontalt. Laravel Horizon viser antall workere, gjennomstrømning og ventetider per kø, og det er slik du sjekker at behandlingen holder tritt med inntaket. Skill køene etter prioritet. Evaluering av varsler skal aldri måtte vente bak en opphopning av historisk ombehandling, så gi behandling, aggregering, varsling og eksport hver sine køer og grupper av workere. Gjør hver jobb idempotent. Strømmer leverer på nytt, workere krasjer midt i en bolk, og nye forsøk skjer, så det å behandle den samme hendelsen to ganger må ikke doble en teller. En hendelsesidentifikator som sjekkes mot et kortlevd sett i Redis, er ofte nok. ## Aggreger i tidsintervaller før du kringkaster Dashbord viser rater, gjennomsnitt, persentiler og trender, ikke enkelthendelser. Beregn disse i workere i faste tidsintervaller, for eksempel per sekund og per minutt, for hver enhet du viser: en celle, en region, en kunde. Hold de løpende aggregatene i Redis, med hasher eller sorterte sett med intervallet som nøkkel, og skriv hvert avsluttet intervall til databasen som historikk. Utformingen av spørringene mot disse historikktabellene betyr like mye som den løpende flyten, fordi brukerne vil zoome ut til en dag eller en uke. På Slump reduserte en ny utforming av cachingen i Redis og optimalisering av spørringer latensen i inntaket, og det var det som holdt sanntidsvisningen oppdatert under belastning. ## Send sammendrag over WebSockets med Reverb eller en driftet tjeneste Broadcasting i Laravel sender hendelser til kanaler som frontend abonnerer på via Laravel Echo. Laravel Reverb er Laravels egen WebSocket-server, og driftede tjenester som Pusher eller Ably fungerer gjennom det samme API-et for broadcasting. - Kringkast etter en tidtaker ut fra aggregert tilstand, ikke én gang per innkommende hendelse - Bruk private kanaler og autoriser hvert abonnement på serveren, slik at brukerne bare ser de enhetene de har lov til å se - Send kompakte øyeblikksbilder eller endringer, ikke hele datasett - Ved ny tilkobling bør klienten laste gjeldende tilstand over HTTP og deretter fortsette strømmen - Kjør flere Reverb-instanser bak en lastbalanserer, med Redis pub/sub mellom dem, når antallet tilkoblinger vokser ## Varsle på dynamiske terskler i stedet for faste grenser Faste terskler svikter i begge retninger på strømmende måletall. Trafikken klokken 3 om natten ligner ikke på trafikken klokken 20, så én enkelt grense slår enten ut hele natten eller overser problemer på dagtid. En dynamisk terskel sammenligner hver nye verdi med et referansenivå lært fra nylig historikk for den samme enheten og det samme tidspunktet i uken. En enkel versjon som er lett å forklare, holder et glidende gjennomsnitt og et standardavvik per enhet og time i uken, og utløser et varsel når verdien holder seg utenfor dette båndet i flere intervaller på rad. På Slump reduserte dynamisk varsling av avvik behovet for manuell overvåking, fordi operatørene ble varslet om reelle avvik i stedet for å følge med på skjermer. - Krev varighet, for eksempel tre intervaller på rad utenfor båndet, for å redusere støy - Hold ett åpent varsel per enhet og vilkår, som oppdateres i stedet for å gjentas - Ta med gjeldende verdi, referansenivået, båndet og en lenke til panelet i hvert varsel - Gå jevnlig gjennom varsler som er dempet eller ignorert, og juster båndet ## Vit når du bør legge til egen strømmeteknologi Laravel med Redis dekker mye, men har sine grenser. Vurder Kafka, Redpanda eller en administrert strømmetjeneste, ofte med en strømprosessor som Apache Flink, når du trenger lang lagring og avspilling av rå hendelser, streng rekkefølge per nøkkel på tvers av mange konsumenter, eller en gjennomstrømning som gjør minnet i Redis til flaskehalsen. Overgangen trenger ikke skje på én gang. Behold Laravel for API-et, dashbordene, håndteringen av varsler og kringkastingen, og sett strømmen foran aggregeringstrinnet. Vi bygger og utvider sanntidssystemer med denne strukturen, fra inntaket til varslingsreglene operatørene er avhengige av. ## Det viktigste - Strøm aldri rå hendelser til nettlesere; kringkast aggregerte sammendrag i et fast tempo. - Hold endepunktet for inntak tynt, og bufre hendelser i Redis for behandling i bolker av workere. - Skill køene etter prioritet, og gjør hver jobb idempotent, slik at nye forsøk ikke kan ødelegge tellere. - Dynamiske terskler basert på nylig historikk gir færre og mer nyttige varsler enn faste grenser. - Legg til Kafka eller en lignende plattform når du trenger avspilling, streng rekkefølge eller et volum utover det Redis takler, og behold Laravel for applikasjonslaget. ## Spørsmål og svar ### Kan Laravel håndtere sanntidsdashbord for data med høyt volum? Ja, når arkitekturen holder tungt arbeid utenfor forespørselsflyten: et tynt endepunkt for inntak, en buffer i Redis, workere i køer som aggregerer i tidsintervaller, og WebSocket-kringkasting av bare sammendrag. Laravel betjener da API-et, dashbordene og varslingen, mens workerne skalerer uavhengig. ### Bør jeg bruke Laravel Reverb eller Pusher til WebSockets? Reverb er Laravels egen WebSocket-server og kjører på din egen infrastruktur, noe som passer team som vil ha kontroll over kostnader og hvor dataene ligger. Pusher eller Ably fjerner driftsarbeidet med å kjøre WebSocket-servere. Begge bruker det samme API-et for broadcasting i Laravel, så du kan bytte senere. ### Hva er en dynamisk terskel i overvåking? En dynamisk terskel er en varslingsgrense som beregnes ut fra nylig historikk for det samme måletallet, den samme enheten og det samme tidspunktet i uken, i stedet for et fast tall. Den tilpasser seg daglige og ukentlige mønstre, slik at varsler utløses ved reelle avvik i stedet for ved normale topper. ## Relaterte tjenester - [Skreddersydd programvare](https://sdk.enterprises/no/services/product-engineering)