Redis — caching i minnet for nettsteder og nettbutikker
Redis er minnelaget bak nettstedene, nettbutikkene og markedsplassene som er bygget på 4buildsite: det holder dataene som brukes oftest — cachede sider, sesjoner, handlekurver, rategrenser — i minnet (RAM), slik at de ikke må hentes fra databasen ved hver forespørsel. Sannhetskilden er fortsatt PostgreSQL; Redis avlaster den for gjentatte forespørsler. Det er inkludert og driftet av plattformen, uten at du trenger å konfigurere noe.
Hva er Redis, og hvorfor ligger dataene i minnet
Redis (REmote DIctionary Server) er en åpen kildekode-database i minnet: den holder dataene i RAM, ikke på disk. På 4buildsite bruker vi den som et cachelag foran PostgreSQL — for data som leses ofte: sider, sesjoner, handlekurver og rategrenser.
Oppslag i RAM krever ingen disklesing, og Redis legger til innebygde datastrukturer (string, hash, liste, set, sorted set, stream) som gir komplekse operasjoner direkte i minnet, uten rundtur til hoveddatabasen. Kommandoer behandles single-threaded, så oppførselen er forutsigbar og uten race conditions.
- Data i RAM, med valgfri persistens til disk (RDB/AOF)
- Innebygde strukturer: hash for sesjoner, sorted set for toppliste og rate limiting, stream for køer
- Single-threaded på kommandoer → forutsigbar oppførsel, uten kompliserte blokkeringer
Caching: sidene og dataene dine, servert fra minnet
Strategien er cache-aside: den første forespørselen leser fra PostgreSQL og lagrer resultatet i Redis med en TTL (levetid); de neste forespørslene henter det direkte fra minnet. Når du redigerer en side, slettes nøkkelen eksplisitt — vi serverer aldri utdaterte data gjennom en blind TTL.
For et presentasjonsnettsted eller en nettbutikk betyr dette at produktlister, menyer, populære sider og innholdsfragmenter leses fra minnet i stedet for fra databasen. Ved toppbelastning (en kampanje, Black Friday) tar Redis unna de gjentatte forespørslene, slik at databasen avlastes.
- Cache-aside med eksplisitt ugyldiggjøring — ingen utdaterte data
- Lagrer sidefragmenter og spørringsresultater, ikke bare hele sider
- Avlaster PostgreSQL for gjentatte spørringer ved trafikktopper
Sesjoner, handlekurv og beskyttelse mot misbruk
Brukersesjoner og refresh-tokens ligger i Redis: rask autentisering, automatisk utløp via TTL og tilbakekalling på alle enheter når noen logger ut eller bytter passord.
Handlekurven i nettbutikker bygget på 4buildsite holdes i Redis for uinnloggede besøkende — raskt, med utløp, uten å blåse opp hoveddatabasen. Redis håndhever også rate limiting på kontaktskjemaer og innlogging, ved hjelp av sorted sets, for å stoppe spam og brute force-forsøk før de når databasen.
- Sesjonslager med automatisk utløp og selektiv tilbakekalling av tokens
- Persistent handlekurv med TTL for anonyme besøkende
- Rate limiting og beskyttelse mot misbruk på skjemaer og autentisering
Sanntid og jobbkøer i bakgrunnen
Redis Pub/Sub og Streams driver sanntidsoppdateringer: en lagerbeholdning som synker live, et varsel i appen, en ordrestatus som endres — alt uten at besøkende må oppdatere siden og uten gjentatt polling som sliter ut serveren.
Tunge oppgaver (behandling av et bilde, generering av en eksport, en synkronisering) legges i en Redis-kø og kjøres av workere i bakgrunnen. En mekanisme for distribuert låsing sørger for at en kritisk operasjon ikke kjøres to ganger.
- Pub/Sub og Streams for live-hendelser (lager, ordrer, varsler)
- Jobbkøer for tung behandling som kjøres asynkront
- Distribuert låsing for operasjoner som ikke må kjøres to ganger
Fordeler og begrensninger
Fordeler
- Cachede data serveres fra minnet, uten spørring mot databasen
- Avlaster PostgreSQL for gjentatte spørringer ved høy trafikk
- Innebygde strukturer for sesjoner, handlekurv, rate limiting og topplister
- Pub/Sub og Streams for sanntidsfunksjoner, uten polling
- Jobbkøer for tung behandling
- Inkludert og driftet av plattformen — null konfigurasjon for deg
Begrensninger
- Dataene ligger i RAM, som er dyrere enn disk → ikke egnet for enorme mengder «kalde» data
- Det er en cache / et hjelpelag, ikke sannhetskilden — permanente data blir i PostgreSQL
- Persistens (RDB/AOF) reduserer, men eliminerer ikke helt, risikoen for å miste de siste sekundene ved et krasj
- Krever en riktig ugyldiggjøringsstrategi, ellers kan det servere utdaterte data
Kort vurdering
Bruk Redis til data som leses ofte eller er kortlivede — caching, sesjoner, handlekurv, rate limiting, sanntid og jobbkøer. Ikke bruk det som hovedlager for data; til det brukes fortsatt PostgreSQL. På 4buildsite har du begge, automatisk tilpasset: du trenger ikke å velge eller konfigurere noe.
Spesifikasjonstabell
| Egenskap | Detalj | Hvor det brukes i buildersen |
|---|---|---|
| Lagringsmedium | RAM (i minnet) | Sider og data leses fra cache i stedet for fra databasen |
| Kjøremodell | Single-threaded behandling av kommandoer | Tellere for rate limiting og distribuert låsing, uten race conditions |
| Datastrukturer | string, hash, list, set, sorted set, stream | Sesjoner, handlekurv, topplister, køer, rate limiting |
| Persistens | RDB-snapshot + AOF-logg | Gjenoppretting etter omstart |
| Utløp | TTL per nøkkel | Handlekurv, sesjoner og cache med automatisk opprydding |
| Sanntid | Pub/Sub + Streams | Live lager, varsler, ordrestatus |
Redis (cache) mot kun database
| Kriterium | Med Redis | Kun PostgreSQL |
|---|---|---|
| Henting av gjentatte data | fra minnet, uten spørring mot databasen | spørring mot databasen ved hver forespørsel |
| Ved høy trafikk | gjentatte spørringer tas av cachen | alle spørringer går til databasen |
| Handlekurv og sesjoner | i minnet, med automatisk utløp (TTL) | tabeller som vokser og belaster databasen |
| Sanntid | innebygd Pub/Sub og Streams | gjentatt polling, kostbart |
| Jobbkøer | innebygde, enkle å bruke | improviserte løsninger eller ingen |
Ofte stilte spørsmål
Hva er Redis, kort fortalt?
En database i minnet (RAM), brukt som lag for cache, sesjoner og sanntid foran hoveddatabasen. Data som leses ofte, hentes fra minnet i stedet for fra databasen.
Hvorfor bruker dere ikke bare PostgreSQL?
PostgreSQL er sannhetskilden (varige data), men Redis serverer gjentatte data fra minnet og tar over handlekurv, sesjoner, rate limiting og sanntid, slik at databasen avlastes ved høy trafikk. De to jobber sammen.
Mister jeg data hvis Redis går ned?
Ikke innholdet på nettstedet: de permanente dataene ligger i PostgreSQL. I Redis ligger bare cache og midlertidige data, og RDB/AOF-persistens reduserer tapene. En omstart av Redis påvirker ikke det publiserte nettstedet ditt.
Må jeg konfigurere Redis selv?
Nei. Det er inkludert og driftet av 4buildsite-plattformen; du får fordel av cachen og sanntidsfunksjonene uten å administrere noe.
Hvordan hjelper Redis en nettbutikk?
Rask handlekurv for besøkende, cachede produktlister, lagerbeholdning oppdatert live og beskyttelse mot misbruk i kassen og på skjemaer — alt uten å belaste databasen.
Hjelper Redis på SEO og Core Web Vitals?
Indirekte: når data kommer fra cache, venter ikke serveren på en databasespørring før den svarer. Det påvirker TTFB (tiden til første byte), som inngår i LCP, en av Core Web Vitals.