Redis — in-memory caching til websites og webshops
Redis er hastighedslaget bag de websites, webshops og marketplaces, der er bygget på 4buildsite: det holder netop de data i hukommelsen (RAM), der skal leveres — cachede sider, sessioner, indkøbskurve, rate limits — og svarer på under et millisekund. PostgreSQL forbliver kilden til sandhed; Redis beskytter den under tung trafik. Det er inkluderet og administreres af platformen, uden nogen konfiguration fra din side.
Hvad Redis er, og hvorfor det er så hurtigt
Redis (REmote DIctionary Server) er en open source in-memory-database: den holder data i RAM i stedet for på disk og svarer derfor på under et millisekund. På 4buildsite bruger vi den som et accelerationslag foran PostgreSQL — til alt, der skal leveres: sider, sessioner, indkøbskurve og rate limits.
I modsætning til en disk er RAM størrelsesordener hurtigere, og Redis tilføjer native datastrukturer (string, hash, list, set, sorted set, stream), der muliggør komplekse operationer direkte i hukommelsen uden en rundtur til hoveddatabasen. Kommandobehandlingen er enkelttrådet, så adfærden er forudsigelig og fri for race conditions.
- Typisk latenstid under 1 ms og over 100.000 operationer i sekundet på en enkelt node
- Native strukturer: hashes til sessioner, sorted sets til ranglister og rate limiting, streams til køer
- Enkelttrådet på kommandoer → forudsigelig adfærd, ingen kompleks låsning
Caching: dine sider og data, leveret fra hukommelsen
Strategien er cache-aside: den første forespørgsel læser fra PostgreSQL og gemmer resultatet i Redis med en TTL (time to live); efterfølgende forespørgsler hentes direkte fra hukommelsen. Når du redigerer en side, invalideres nøglen eksplicit — vi leverer aldrig forældede data via en blind TTL.
For et præsentationssite eller en webshop betyder det, at produktlister, menuer, populære sider og indholdsfragmenter leveres fra hukommelsen, uden at overbelaste databasen. Ved spidsbelastninger (en kampagne, Black Friday) absorberer Redis de gentagne forespørgsler og holder sitet hurtigt.
- Cache-aside med eksplicit invalidering — ingen forældede data
- Cacher sidefragmenter og forespørgselsresultater, ikke kun hele sider
- Beskytter PostgreSQL ved trafikspidser og forkorter svartiderne
Sessioner, indkøbskurv og beskyttelse mod misbrug
Brugersessioner og refresh-tokens ligger i Redis: hurtig autentificering, automatisk udløb via TTL og tilbagekaldelse på alle enheder, når nogen logger ud eller skifter adgangskode.
Indkøbskurven i webshops bygget på 4buildsite opbevares i Redis for ikke-loggede besøgende — hurtigt, med udløb og uden at belaste hoveddatabasen. Redis håndhæver også rate limiting på kontaktformularer og login ved hjælp af sorted sets og stopper spam og brute force-forsøg, før de når databasen.
- Sessionslager med automatisk udløb og selektiv tilbagekaldelse af tokens
- Vedvarende indkøbskurv med TTL til anonyme besøgende
- Rate limiting og beskyttelse mod misbrug på formularer og autentificering
Realtid og baggrundsjobkøer
Redis Pub/Sub og Streams driver realtidsopdateringer: lagerbeholdning, der falder live, en notifikation i appen, en ændret ordrestatus — alt sammen uden at den besøgende opdaterer siden og uden gentagen polling, der belaster serveren.
Tunge opgaver (behandling af et billede, generering af en eksport, en synkronisering) kommer ind i en Redis-kø og køres af baggrundsworkers uden for svarvejen. En distribueret låsemekanisme sikrer, at en kritisk operation ikke kører to gange.
- Pub/Sub og Streams til live-hændelser (lager, ordrer, notifikationer)
- Jobkøer til tung behandling, der køres asynkront
- Distribueret låsning til operationer, der ikke må køre to gange
Fordele og begrænsninger
Fordele
- Svar på under 1 ms: cachede data leveres næsten øjeblikkeligt
- Reducerer PostgreSQL-belastningen markant under tung trafik
- Native strukturer til sessioner, indkøbskurv, rate limiting og ranglister
- Pub/Sub og Streams til realtidsfunktioner, uden polling
- Jobkøer til tung behandling
- Inkluderet og administreret af platformen — ingen konfiguration for dig
Begrænsninger
- Data ligger i RAM, som er dyrere end disk → ikke til store mængder »kolde« data
- Det er et cache- / hjælpelag, ikke kilden til sandhed — permanente data bliver i PostgreSQL
- Persistens (RDB/AOF) reducerer, men fjerner ikke helt risikoen for at miste de sidste sekunder ved et nedbrud
- Kræver en korrekt invalideringsstrategi, ellers kan den levere forældede data
Kort konklusion
Brug Redis til alt, der skal være øjeblikkeligt — caching, sessioner, indkøbskurv, rate limiting, realtid og jobkøer. Brug det ikke som primært datalager; det er PostgreSQL til. På 4buildsite får du begge dele, koblet sammen automatisk: du behøver ikke vælge eller konfigurere noget.
Specifikationstabel
| Egenskab | Detalje | Hvor det bruges i buildere |
|---|---|---|
| Latenstid | < 1 ms (in-memory) | Sider og data leveres øjeblikkeligt |
| Gennemløb | > 100.000 ops/s pr. node | Tung trafik uden at databasen bukker under |
| Datastrukturer | string, hash, list, set, sorted set, stream | Sessioner, indkøbskurv, ranglister, køer, rate limiting |
| Persistens | RDB-snapshot + AOF-log | Hurtig genopretning efter en genstart |
| Udløb | TTL pr. nøgle | Selvrensende indkøbskurv, sessioner og cache |
| Realtid | Pub/Sub + Streams | Live lager, notifikationer, ordrestatus |
Redis (cache) vs. kun database
| Kriterium | Med Redis | Kun PostgreSQL |
|---|---|---|
| Svartid for gentagne data | under 1 ms, fra hukommelsen | titusinder af ms, en forespørgsel ved hver anmodning |
| Under tung trafik | databasen er beskyttet, skalerer let | databasen går i stå, risiko for timeouts |
| Indkøbskurv og sessioner | hurtige, med automatisk udløb | tabeller, der vokser og belaster databasen |
| Realtid | native Pub/Sub og Streams | gentagen polling, dyrt |
| Jobkøer | native, enkle at bruge | hjemmestrikkede eller manglende løsninger |
Ofte stillede spørgsmål
Hvad er Redis, kort sagt?
En ekstremt hurtig in-memory-database, der bruges som cache-, session- og realtidslag foran hoveddatabasen. Den svarer på under et millisekund.
Hvorfor ikke bare bruge PostgreSQL?
PostgreSQL er kilden til sandhed (varige data), men Redis leverer gentagne data på under et millisekund og overtager indkøbskurv, sessioner, rate limiting og realtid, så databasen beskyttes under tung trafik. De to arbejder sammen.
Mister jeg data, hvis Redis går ned?
Ikke dit sites indhold: de permanente data ligger i PostgreSQL. Redis rummer kun cache og midlertidige data, og RDB/AOF-persistens reducerer tab. En genstart af Redis påvirker ikke dit publicerede site.
Skal jeg selv konfigurere Redis?
Nej. Det er inkluderet og administreres af 4buildsite-platformen; du får hastigheden og realtidsfunktionerne uden at skulle administrere noget.
Hvordan hjælper Redis en webshop?
En hurtig indkøbskurv til besøgende, cachede produktlister, live opdateret lagerbeholdning og beskyttelse mod misbrug ved checkout og på formularer — alt sammen uden at belaste databasen.
Hjælper Redis på sitets hastighed og SEO?
Indirekte: data, der leveres fra hukommelsen, forkorter serverens svartid (TTFB, tiden til den første byte). Det er en teknisk forbedring, ikke en garanti for bedre placeringer i Google.