Redis — cachning i minnet för webbplatser och butiker
Redis är hastighetslagret bakom webbplatser, butiker och marknadsplatser som byggs på 4buildsite: det håller de data som läses ofta i minnet (RAM) — cachade sidor, sessioner, varukorgar, hastighetsgränser. Sanningskällan förblir PostgreSQL; Redis avlastar den vid hög trafik. Det ingår och hanteras av plattformen, utan någon konfiguration från din sida.
Vad Redis är och hur det fungerar
Redis (REmote DIctionary Server) är en databas i minnet med öppen källkod: den håller data i RAM, inte på disk. På 4buildsite använder vi den som ett accelerationslager framför PostgreSQL — för allt som läses ofta: sidor, sessioner, varukorgar och hastighetsgränser.
Till skillnad från en disk är RAM flera storleksordningar snabbare, och Redis lägger till inbyggda datastrukturer (string, hash, list, set, sorted set, stream) som möjliggör komplexa operationer direkt i minnet, utan en tur och retur till huvuddatabasen. Kommandobearbetningen är entrådad (single-threaded), så beteendet är förutsägbart och fritt från race conditions.
- Typisk latens under 1 ms och över 100 000 operationer per sekund på en enda nod
- Inbyggda strukturer: hashar för sessioner, sorted set för topplistor och rate limiting, stream för köer
- Entrådad kommandohantering → förutsägbart beteende, utan komplexa blockeringar
Cachning: dina sidor och data, serverade från minnet
Strategin är cache-aside: den första förfrågan läser från PostgreSQL och sparar resultatet i Redis med en TTL (livslängd); följande förfrågningar hämtar det direkt från minnet. När du redigerar en sida raderas nyckeln uttryckligen — vi serverar aldrig föråldrad data via en blind TTL.
För en presentationssajt eller en butik innebär det att produktlistor, menyer, populära sidor och innehållsfragment levereras från minnet, utan att överbelasta databasen. Vid toppar (en kampanj, Black Friday) absorberar Redis de upprepade förfrågningarna.
- Cache-aside med explicit invalidering — ingen föråldrad data
- Lagrar sidfragment och frågeresultat, inte bara hela sidor
- Skyddar PostgreSQL vid trafiktoppar och minskar svarstiderna
Sessioner, varukorg och skydd mot missbruk
Användarsessioner och refresh-token ligger i Redis: automatiskt utgående via TTL och återkallning på alla enheter när någon loggar ut eller byter lösenord.
Varukorgen i butiker som byggs på 4buildsite hålls i Redis för oinloggade besökare — med utgångstid, utan att svälla huvuddatabasen. Redis tillämpar också rate limiting på kontaktformulär och inloggning, med hjälp av sorted sets, för att stoppa spam och brute force-försök innan de når databasen.
- Sessionslagring med automatisk utgång och selektiv återkallning av token
- Beständig varukorg med TTL för anonyma besökare
- Rate limiting och skydd mot missbruk på formulär och autentisering
Realtid och jobbköer i bakgrunden
Redis Pub/Sub och Streams driver realtidsuppdateringarna: ett lagersaldo som minskar live, en notis i appen, statusen på en order som ändras — allt utan att besökaren behöver uppdatera sidan och utan upprepad polling som sliter på servern.
Tunga uppgifter (bearbetning av en bild, generering av en export, en synkronisering) hamnar i en Redis-kö och körs av workers i bakgrunden, så att besökarens förfrågan inte blockeras av dem. En mekanism för distribuerad låsning garanterar att en kritisk operation inte körs två gånger.
- Pub/Sub och Streams för liveevenemang (lager, ordrar, notiser)
- Jobbköer för tung bearbetning som körs asynkront
- Distribuerad låsning för operationer som inte får köras två gånger
Fördelar och begränsningar
Fördelar
- Cachad data läses från minnet
- Minskar belastningen på PostgreSQL dramatiskt vid hög trafik
- Inbyggda strukturer för sessioner, varukorg, rate limiting och topplistor
- Pub/Sub och Streams för realtidsfunktioner, utan polling
- Jobbköer för tung bearbetning, utan att blockera besökaren
- Ingår och hanteras av plattformen — noll konfiguration för dig
Begränsningar
- Data ligger i RAM, som är dyrare än disk → inte avsett för enorma mängder ”kall” data
- Det är en cache / ett hjälplager, inte sanningskällan — permanent data förblir i PostgreSQL
- Persistensen (RDB/AOF) minskar men eliminerar inte helt risken att förlora de sista sekunderna vid en krasch
- Kräver en korrekt invalideringsstrategi, annars kan den servera föråldrad data
Kort slutsats
Använd Redis för allt som läses ofta — cachning, sessioner, varukorg, rate limiting, realtid och jobbköer. Använd det inte som huvudlager för data; där förblir PostgreSQL. På 4buildsite har du båda, automatiskt avpassade: du behöver varken välja eller konfigurera något.
Specifikationstabell
| Förmåga | Detalj | Var det används i buildern |
|---|---|---|
| Latens | < 1 ms (i minnet) | Sidor och data läses från minnet |
| Genomströmning | > 100 000 ops/s per nod | Hög trafik utan att databasen faller |
| Datastrukturer | string, hash, list, set, sorted set, stream | Sessioner, varukorg, topplistor, köer, rate limiting |
| Persistens | RDB-snapshot + AOF-logg | Återhämtning efter en omstart (RDB/AOF) |
| Utgång | TTL per nyckel | Varukorg, sessioner och cache med automatisk rensning |
| Realtid | Pub/Sub + Streams | Live-lager, notiser, orderstatus |
Redis (cache) jämfört med enbart databas
| Kriterium | Med Redis | Enbart PostgreSQL |
|---|---|---|
| Svarstid för upprepade data | under 1 ms, från minnet | tiotals ms, en fråga vid varje förfrågan |
| Vid hög trafik | databasen skyddad, skalar enkelt | databasen blir överbelastad, risk för timeouts |
| Varukorg och sessioner | med automatisk utgång | tabeller som växer och belastar databasen |
| Realtid | inbyggda Pub/Sub och Streams | upprepad polling, kostsamt |
| Jobbköer | inbyggda, enkla att använda | hemsnickrade lösningar eller inga alls |
Vanliga frågor
Vad är Redis, i korthet?
En databas i minnet, som används som lager för cache, sessioner och realtid framför huvuddatabasen. Den lagrar data i RAM, inte på disk.
Varför använder ni inte bara PostgreSQL?
PostgreSQL är sanningskällan (beständig data), men Redis serverar upprepade data från minnet och tar över varukorgen, sessionerna, rate limiting och realtid, vilket skyddar databasen vid hög trafik. De två arbetar tillsammans.
Förlorar jag data om Redis går ner?
Inte webbplatsens innehåll: permanent data finns i PostgreSQL. I Redis ligger bara cache och tillfälliga data, och RDB/AOF-persistensen minskar förlusterna. En omstart av Redis påverkar inte din publicerade webbplats.
Måste jag konfigurera Redis själv?
Nej. Det ingår och hanteras av 4buildsite-plattformen; du får realtidsfunktionerna utan att administrera något.
Hur hjälper Redis en webbutik?
Varukorg för besökare, cachade produktlistor, lagersaldo som uppdateras live och skydd mot missbruk vid kassan och i formulär — allt utan att belasta databasen.
Hjälper Redis SEO och Core Web Vitals?
Ja, indirekt: korta svarstider kan påverka TTFB och Core Web Vitals, signaler som spelar roll både för Google och för användarupplevelsen.