--- title: "Valós idejű dashboardok: Laravel, Redis és WebSockets" description: "Valós idejű dashboardok és riasztások nagy volumenű adatfolyamokra Laravellel: pufferelt betöltés, sorok, broadcasting, aggregálás és dinamikus küszöbök." canonical: https://sdk.enterprises/hu/insights/real-time-dashboards-laravel language: hu --- # Valós idejű dashboardok: Laravel, Redis és WebSockets Frissítve: 2026-09-25 > A Laravel képes nagy volumenű adatfolyamok fölött valós idejű dashboardokat kiszolgálni, ha a nyers események soha nem jutnak el a böngészőig: pufferelje a betöltést Redisben, dolgozza fel sorba állított workerekkel, előre aggregálja időrekeszekbe, és WebSocketeken keresztül csak összesítéseket küldjön ki. Rögzített határértékek helyett a közelmúlt adataiból tanult dinamikus küszöbökre riasszon, és vezessen be dedikált streamingplatformot, amikor a visszajátszás, a sorrend vagy a volumen igényei kinövik a Redis-alapú sorokat. ## Tartsa távol a nyers eseményeket a böngészőtől A valós idejű dashboardok leggyakoribb hibája, hogy minden beérkező eseményt minden csatlakozott képernyőre kiküldenek. Nagy volumennél a böngészők lemaradnak, a WebSocket-szerver telítődik, és a grafikon amúgy is olvashatatlanná válik. Ossza a rendszert négy szakaszra: betöltés, feldolgozás, aggregálás és kiküldés. Mindegyik szakasznak saját kapacitása van, és lelassulhat anélkül, hogy a többit is magával rántaná. A dashboard nem nyers eseményeket, hanem aggregált frissítéseket kap rögzített ütemben, például panelenként másodpercenként egyszer. Mérnökeink ezt a felépítést alkalmazták a Slump platformon, amely dél-spanyolországi operátorok számára valós időben figyeli az 5G-hálózati trendeket és a kapacitásmutatókat, és előrejelzi a telítődést. A platform Laravel 11 és 12 alapú backendje nagy volumenű streamingadatokat tölt be. ## Puffereljen a betöltésnél, hogy a forgalmi csúcsokból ne legyen leállás A betöltési végpont a lehető legkevesebbet tegye: validálja az adatcsomagot, fűzze hozzá egy pufferhez, és térjen vissza. Az elemzés, a dúsítás és az adatbázisba írás a workerek dolga. Mérsékelt volumennél a Redis jól működik pufferként. Tegye az eseményeket egy Redis-listába vagy -streambe, és a workerek kötegekben vegyék ki őket, mert egyetlen kötegelt beszúrás sokkal olcsóbb az adatbázisnak, mint több száz egysoros beszúrás. - Validálja a sémát, és a hibás eseményeket már a peremen utasítsa el - Válaszoljon gyorsan, és a kérésen belül soha ne írjon az elsődleges adatbázisba - A pufferből kötegekben olvasson, ne feladatonként egy eseményt - Korlátozza a puffer hosszát, és riasszon, ha nő, hogy a visszatorlódás (backpressure) látható legyen, mielőtt adatvesztés lesz belőle ## Skálázza a feldolgozást külön sorokkal és a Horizonnal A Redisre épülő Laravel-sorok vízszintesen bővíthető workereket adnak. A Laravel Horizon soronként mutatja a workerek számát, az áteresztőképességet és a várakozási időket, így ellenőrizheti, hogy a feldolgozás lépést tart-e a betöltéssel. Válassza szét a sorokat prioritás szerint. A riasztások kiértékelése soha ne várjon egy történeti újrafeldolgozásból eredő torlódás mögött, ezért a feldolgozás, az aggregálás, a riasztás és az exportok kapjanak saját sorokat és workerkészleteket. Legyen minden feladat idempotens. A streamek újrakézbesítenek, a workerek köteg közben összeomlanak, és vannak újrapróbálkozások, ezért ugyanannak az eseménynek a kétszeri feldolgozása nem duplázhat meg egy számlálót. Gyakran elég egy eseményazonosító, amelyet egy rövid életű Redis-halmazban ellenőriz. ## Aggregáljon időrekeszekbe, mielőtt kiküldi az adatokat A dashboardok arányokat, átlagokat, percentiliseket és trendeket mutatnak, nem egyedi eseményeket. Ezeket a workerekben számolja ki rögzített időrekeszekbe, például másodpercenként és percenként, minden megjelenített entitásra: egy cellára, egy régióra, egy ügyfélre. Az élő aggregátumokat tartsa Redisben, rekeszenként kulcsolt hashekben vagy rendezett halmazokban, és minden lezárt rekeszt írjon az adatbázisba a történeti adatokhoz. A történeti táblák lekérdezéseinek tervezése ugyanolyan fontos, mint az élő útvonal, mert a felhasználók napi vagy heti nézetre is váltanak. A Slumpnál a Redis-gyorsítótárazás újratervezése és a lekérdezések optimalizálása csökkentette a betöltési késleltetést, és ez tartotta naprakészen az élő nézetet terhelés alatt. ## Összesítéseket küldjön WebSocketeken, Reverbbel vagy hosztolt szolgáltatással A Laravel broadcasting csatornákra küld eseményeket, amelyekre a frontend a Laravel Echón keresztül iratkozik fel. A Laravel Reverb a Laravel saját WebSocket-szervere, és a hosztolt szolgáltatások, például a Pusher vagy az Ably, ugyanazon a broadcasting API-n keresztül működnek. - Időzítő alapján, az aggregált állapotból küldjön, ne minden beérkező eseménynél - Használjon privát csatornákat, és minden feliratkozást a szerveren engedélyezzen, hogy a felhasználók csak azokat az entitásokat lássák, amelyeket láthatnak - Tömör pillanatképeket vagy változásokat (deltákat) küldjön, ne teljes adathalmazokat - Újracsatlakozáskor a kliens HTTP-n töltse be az aktuális állapotot, majd folytassa a streamet - A kapcsolatok számának növekedésével futtasson több Reverb-példányt egy terheléselosztó mögött, köztük Redis pub/subbal ## Rögzített határértékek helyett dinamikus küszöbökre riasszon Streamingmetrikáknál a rögzített küszöbök mindkét irányban kudarcot vallanak. Hajnali 3-kor a forgalom egészen másképp néz ki, mint este 8-kor, így egyetlen határérték vagy egész éjjel riaszt, vagy nappal nem veszi észre a problémákat. A dinamikus küszöb minden új értéket egy alapvonalhoz hasonlít, amelyet ugyanannak az entitásnak a közelmúltbeli adataiból tanult, a hét ugyanazon időszakára. Egy egyszerű, megmagyarázható változat entitásonként és a hét minden órájára gördülő átlagot és szórást tart nyilván, és riaszt, ha az érték több egymást követő rekeszen át a sávon kívül marad. A Slumpnál a dinamikus anomáliariasztás csökkentette a kézi figyelést, mert az operátorokat valódi eltéréseknél riasztották, és nem kellett folyamatosan a képernyőket nézniük. - Követeljen meg tartósságot, például három egymást követő sávon kívüli rekeszt, a zaj csökkentésére - Entitásonként és feltételenként egy nyitott riasztás legyen, amelyet frissítenek, nem ismételnek - Minden riasztásban szerepeljen az aktuális érték, az alapvonal, a sáv és egy link a panelhez - Rendszeresen nézze át az elnémított és figyelmen kívül hagyott riasztásokat, és hangolja a sávot ## Tudja, mikor érdemes dedikált streamingtechnológiát bevezetni A Laravel és a Redis sok mindent lefed, de vannak korlátai. Fontolja meg a Kafkát, a Redpandát vagy egy menedzselt streamingszolgáltatást, gyakran egy streamfeldolgozóval, például az Apache Flinkkel együtt, ha a nyers események hosszú megőrzésére és visszajátszására, kulcsonként szigorú sorrendre sok fogyasztón át, vagy olyan áteresztőképességre van szüksége, amelynél a Redis memóriája válik szűk keresztmetszetté. Az átállásnak nem kell egyszerre megtörténnie. Tartsa meg a Laravelt az API-hoz, a dashboardokhoz, a riasztáskezeléshez és a kiküldéshez, a streamet pedig tegye az aggregálási szakasz elé. Ilyen felépítésű valós idejű rendszereket építünk és bővítünk, a betöltéstől azokig a riasztási szabályokig, amelyekre az operátorok támaszkodnak. ## A legfontosabbak - Soha ne streameljen nyers eseményeket a böngészőkbe; aggregált összesítéseket küldjön rögzített ütemben. - A betöltési végpont maradjon vékony, az eseményeket pedig pufferelje Redisben, hogy a workerek kötegekben dolgozzák fel őket. - Válassza szét a sorokat prioritás szerint, és legyen minden feladat idempotens, hogy az újrapróbálkozások ne rontsák el a számlálókat. - A közelmúlt adataira épülő dinamikus küszöbök kevesebb, de hasznosabb riasztást adnak, mint a rögzített határértékek. - Vezessen be Kafkát vagy hasonló platformot, ha visszajátszásra, szigorú sorrendre vagy a Redis képességein túli volumenre van szüksége, az alkalmazásréteghez pedig tartsa meg a Laravelt. ## GYIK ### Elbírja a Laravel a nagy volumenű adatok valós idejű dashboardjait? Igen, ha az architektúra távol tartja a nehéz munkát a kérések útvonalától: vékony betöltési végpont, Redis-puffer, időrekeszekbe aggregáló, sorba állított workerek, és WebSocketen csak összesítések kiküldése. A Laravel ekkor az API-t, a dashboardokat és a riasztást szolgálja ki, a workerek pedig tőle függetlenül skálázódnak. ### Laravel Reverb vagy Pusher a WebSocketekhez? A Reverb a Laravel saját WebSocket-szervere, és a saját infrastruktúráján fut, ami azoknak a csapatoknak való, amelyek kézben akarják tartani a költségeket és az adatok helyét. A Pusher vagy az Ably leveszi a válláról a WebSocket-szerverek üzemeltetésének munkáját. Mindkettő ugyanazt a Laravel broadcasting API-t használja, így később válthat. ### Mi az a dinamikus küszöb a monitorozásban? A dinamikus küszöb olyan riasztási határérték, amelyet nem rögzített számként adnak meg, hanem ugyanannak a metrikának, entitásnak és heti időszaknak a közelmúltbeli adataiból számolnak. Alkalmazkodik a napi és heti mintázatokhoz, így a riasztások valódi eltéréseknél szólalnak meg, nem a normál csúcsoknál. ## Kapcsolódó szolgáltatások - [Egyedi szoftver](https://sdk.enterprises/hu/services/product-engineering)