Redis — memóriában tárolt gyorsítótár weboldalakhoz és webáruházakhoz
A Redis gyorsítórétegként áll a 4buildsite-on épülő webhelyek, webáruházak és piacterek mögött: pontosan azokat az adatokat tartja a memóriában (RAM), amelyeket gyorsan kell kiszolgálni — gyorsítótárazott oldalakat, munkameneteket, kosarakat, forgalomkorlátozásokat —, és alacsony késleltetéssel válaszol. Az igazság forrása továbbra is a PostgreSQL marad; a Redis nagy forgalomnál megvédi, a látogató pedig a gyorsítótárból kapja a tartalmat. Benne van a csomagban, a platform üzemelteti, neked semmit sem kell beállítanod.
Mi a Redis, és mitől ilyen gyors
A Redis (REmote DIctionary Server) nyílt forráskódú, memóriában dolgozó adatbázis: az adatokat a RAM-ban tartja, nem a lemezen, ezért alacsony késleltetéssel válaszol. A 4buildsite-on gyorsítórétegként használjuk a PostgreSQL előtt — mindenhez, amit gyorsan kell kiszolgálni: oldalakhoz, munkamenetekhez, kosarakhoz és forgalomkorlátozáshoz.
A RAM nagyságrendekkel gyorsabb a lemeznél, a Redis pedig natív adatszerkezeteket ad hozzá (string, hash, lista, set, sorted set, stream), amelyekkel összetett műveletek is elvégezhetők közvetlenül a memóriában, a főadatbázis megkerülésével. A parancsokat egy szálon dolgozza fel, így kiszámítható a viselkedése, és nem lépnek fel versenyhelyzetek.
- Jellemzően 1 ms alatti késleltetés és másodpercenként több mint 100 000 művelet egyetlen csomóponton
- Natív szerkezetek: hash a munkamenetekhez, sorted set a ranglistákhoz és a rate limitinghez, stream a sorokhoz
- Egyszálú parancsfeldolgozás → kiszámítható működés, összetett holtpontok nélkül
Gyorsítótárazás: gyorsítótárból kiszolgált oldalak és adatok
A stratégia a cache-aside: az első kérés a PostgreSQL-ből olvas, majd az eredményt TTL-lel (élettartammal) elteszi a Redisbe; a további kérések már közvetlenül a memóriából kapják meg. Amikor szerkesztesz egy oldalt, a kulcsot kifejezetten töröljük — soha nem szolgálunk ki elavult adatot vak TTL-re bízva.
Egy bemutatkozó oldal vagy egy webáruház esetében ez azt jelenti, hogy a terméklisták, a menük, a népszerű oldalak és a tartalomrészletek nagy forgalomnál is a gyorsítótárból érkeznek, anélkül hogy túlterhelnék az adatbázist. Csúcsidőben (egy kampány vagy a Black Friday alatt) a Redis felfogja az ismétlődő kéréseket, és az adatbázis nem telik meg a kérések tömegével.
- Cache-aside kifejezett érvénytelenítéssel — elavult adat nélkül
- Nemcsak teljes oldalakat tárol, hanem oldalrészleteket és lekérdezési eredményeket is
- Forgalmi csúcsokon megvédi a PostgreSQL-t, és csökkenti a válaszidőt
Munkamenetek, kosár és visszaélés elleni védelem
A felhasználói munkamenetek és a frissítő tokenek a Redisben vannak: TTL szerinti automatikus lejárat, és visszavonás minden eszközön, amint valaki kijelentkezik vagy jelszót cserél.
A 4buildsite-on épült webáruházak kosarát be nem jelentkezett látogatóknál a Redis tárolja — lejárattal, anélkül hogy a főadatbázis feleslegesen hízna. Szintén a Redis végzi a kapcsolatfelvételi űrlapok és a bejelentkezés forgalomkorlátozását sorted set alapon, hogy a spam és a nyers erővel próbálkozás még az adatbázis előtt fennakadjon.
- Munkamenettár automatikus lejárattal és tokenek célzott visszavonásával
- Megmaradó kosár TTL-lel a névtelen látogatóknak
- Rate limiting és visszaélés elleni védelem az űrlapokon és a bejelentkezésnél
Valós idejű működés és háttérben futó feladatsorok
A Redis Pub/Sub és a Streams hajtja a valós idejű frissítéseket: élőben fogyó készlet, alkalmazáson belüli értesítés, változó rendelési státusz — mindez úgy, hogy a látogatónak nem kell frissítenie az oldalt, és a szervert sem fárasztja folyamatos lekérdezgetés.
A nehéz feladatok (egy kép feldolgozása, egy export elkészítése, egy szinkronizálás) Redis-sorba kerülnek, és a háttérben futó workerek végzik el őket, hogy a látogató ne a feldolgozásra várjon. Elosztott zárolás gondoskodik arról, hogy egy kritikus művelet ne fusson le kétszer.
- Pub/Sub és Streams az élő eseményekhez (készlet, rendelések, értesítések)
- Feladatsorok a nehéz, aszinkron módon futó feldolgozásokhoz
- Elosztott zárolás azokhoz a műveletekhez, amelyek nem futhatnak le kétszer
Előnyök és korlátok
Előnyök
- Jellemzően 1 ms alatti válasz: a gyorsítótárazott adatok a memóriából érkeznek
- Nagy forgalomnál drasztikusan csökkenti a PostgreSQL terhelését
- Natív szerkezetek a munkamenetekhez, a kosárhoz, a rate limitinghez és a ranglistákhoz
- Pub/Sub és Streams a valós idejű funkciókhoz, folyamatos lekérdezgetés nélkül
- Feladatsorok a nehéz feldolgozásokhoz, a háttérben futó workerekkel
- Benne van a csomagban, a platform üzemelteti — neked nulla beállítás
Korlátok
- Az adatok a RAM-ban vannak, ami drágább a lemeznél → nem ritkán használt, hatalmas adatmennyiséghez való
- Gyorsítótár, azaz segédréteg, nem az igazság forrása — a tartós adatok a PostgreSQL-ben maradnak
- A perzisztencia (RDB/AOF) csökkenti, de nem szünteti meg teljesen az utolsó másodpercek elvesztésének kockázatát összeomláskor
- Átgondolt érvénytelenítési stratégiát igényel, különben elavult adatot szolgálhat ki
Rövid értékelés
A Redist mindenre használd, amit gyorsan kell kiszolgálni — gyorsítótárazásra, munkamenetekre, kosárra, rate limitingre, valós idejű funkciókra és feladatsorokra. Fő adattárnak viszont ne: erre továbbra is a PostgreSQL való. A 4buildsite-on mindkettőt megkapod, automatikusan összehangolva: nem kell választanod, és beállítanod sem kell semmit.
Specifikációs táblázat
| Képesség | Részlet | Hol jelenik meg a builderben |
|---|---|---|
| Késleltetés | < 1 ms (memóriában) | Gyorsítótárból kiszolgált oldalak és adatok |
| Átbocsátás | > 100 000 művelet/s csomópontonként | Nagy forgalom, az adatbázis védelmével |
| Adatszerkezetek | string, hash, list, set, sorted set, stream | Munkamenetek, kosár, ranglisták, sorok, rate limiting |
| Perzisztencia | RDB-pillanatkép és AOF-napló | Helyreállás újraindítás után |
| Lejárat | Kulcsonkénti TTL | Önmagát takarító kosár, munkamenet és gyorsítótár |
| Valós idő | Pub/Sub és Streams | Élő készlet, értesítések, rendelési státusz |
Redis (gyorsítótár) a csak adatbázisra épülő megoldással szemben
| Szempont | Redisszel | Csak PostgreSQL |
|---|---|---|
| Válaszidő ismétlődő adatoknál | 1 ms alatt, a memóriából | több tíz ezredmásodperc, minden kérésnél új lekérdezés |
| Nagy forgalomnál | az adatbázis védett, könnyen skálázódik | az adatbázis feltorlódik, időtúllépés fenyeget |
| Kosár és munkamenetek | gyorsak, automatikus lejárattal | növekvő táblák, amelyek terhelik az adatbázist |
| Valós idő | natív Pub/Sub és Streams | ismétlődő lekérdezgetés, drágán |
| Feladatsorok | natívak, egyszerűen használhatók | rögtönzött megoldások vagy semmi |
Gyakori kérdések
Mi a Redis röviden?
Memóriában dolgozó adatbázis, amely gyorsítótár-, munkamenet- és valós idejű rétegként ül a főadatbázis előtt. Jellemzően 1 ms alatt válaszol, a gyorsítótárazott adatokat pedig a memóriából adja ki.
Miért nem elég csak a PostgreSQL?
A PostgreSQL az igazság forrása (tartós adatok), a Redis viszont az ismétlődően lekért adatokat a memóriából szolgálja ki, és átveszi a kosarat, a munkameneteket, a rate limitinget és a valós idejű működést, így nagy forgalomnál megvédi az adatbázist. A kettő együtt dolgozik.
Elvesznek az adataim, ha a Redis leáll?
A webhely tartalma nem: a tartós adatok a PostgreSQL-ben vannak. A Redisben csak gyorsítótár és ideiglenes adatok vannak, az RDB/AOF perzisztencia pedig mérsékli a veszteséget.
Nekem kell beállítanom a Redist?
Nem. Benne van a csomagban, és a 4buildsite platform üzemelteti; te a gyorsítótárazás és a valós idejű funkciók előnyeit élvezed, üzemeltetned semmit sem kell.
Miben segít a Redis egy webáruháznak?
Kosár a látogatóknak, gyorsítótárazott terméklisták, élőben frissülő készlet, valamint visszaélés elleni védelem a pénztárnál és az űrlapokon — mindez az adatbázis tehermentesítésével.
Segít a Redis a SEO-ban és a Core Web Vitals mutatókban?
Igen, közvetve: a rövid válaszidő a TTFB-re hat, amely a Core Web Vitals mutatókhoz is hozzájárul, és a felhasználói élmény szempontjából is számít.