Redis 8: Nye funktioner og beslutninger om opgradering for hostingudbydere

Redis 8 – en korrekt indplacering

Redis 8 betegner en platformgeneration, ikke nødvendigvis en egnet målversion for alle installationer. Redis 8.0 var den første udgivelse, der blev lanceret i maj 2025. Ved en Redis-opdatering skal hostingudbydere dog vælge den konkrete minor- og patch-version, der skal anvendes, samt dens supportstatus og kompatibilitet med deres egen servicemodel.

Pr. 30. september 2026 angiver Redis-versionsstyringen Redis 8.10 som den nyeste version på listen GA-standardudgivelse linje 8. Også 8.4, 8.6 og 8.8 er opført som GA. Den højere minor-version er dog ikke et generelt mål: Patch-status, anvendte funktioner, klientkompatibilitet og det planlagte vedligeholdelsesvindue indgår fortsat i udvælgelsen.

Redis 8.0 er en standardudgivelse, hvor udgivelsen af sikkerhedsrettelser og rettelser til kritiske fejl ifølge versionsstyringen ophører den 1. december 2026. Redis 8.2 er derimod klassificeret som Udvidet udgivelse indtil den 1. september 2030. For konservative Managed-tilbud kan dette fastlagte supportvindue derfor passe bedre til produktcyklussen; det erstatter dog ikke en vurdering af en passende patch-status.

Redis Open Source 8 er den serverserie, der indeholder de open source-funktioner, der behandles i denne artikel. Heraf adskiller sig Redis Software: en kommerciel produktserie til andre klynge- og enterprise-driftsmodeller. Det faktum, at Redis Software 8.0.x understøtter flere Redis-databasversioner, betyder ikke, at dens ekstra produktfunktioner er egenskaber ved en almindelig Redis Open Source-installation.

Valkey er heller ikke en variant af Redis 8, men en selvstændig fork med egen udvikling og egne beslutninger vedrørende kompatibilitet og licens. Hvis man vurderer alternativer, bør man derfor undersøge protokoladfærd, funktionsomfang, migrationsvej og brugsbetingelser hver for sig. Et versionsskift inden for Redis kan ikke sidestilles med et skift til en fork.

Integrerede stack-komponenter i Redis 8

Den mest markante ændring i Redis 8 er integreret distribution De hidtidige Redis-stack-komponenter. Redis Search, JSON, Time Series samt probabilistiske datastrukturer som Bloom- og Cuckoo-filtre, Count-Min Sketch, Top-K og t-digest indgår i Redis Open Source 8. I den første udgave, Redis 8.0.0, blev Vector Set også inkluderet, men der blev det udtrykkeligt markeret som en forhåndsvisning.

For udbydere forenkler det produktvedligeholdelsen, når en tjeneste rent faktisk har brug for dokumentdata, søgning eller tidsserier. Komponenterne versioneres og leveres sammen med Redis. Dermed undgår man behovet for at afstemme uafhængigt installerede stack-moduler med serverversionen; samtidig kan et enkelt integreret modul ikke opdateres uafhængigt af Redis-udgivelsen.

Vektorsæt beskrives i den aktuelle Redis-dokumentation som en selvstændig datatype med kommandoer fra og med Redis 8.0. Det fremgår imidlertid af preview-betegnelsen for den oprindelige udgivelse, at et hostingtilbud ikke alene på baggrund af Redis 8.0.0 bør konkludere, at systemet er fuldt ud klar til produktionsbrug. Det afgørende er udgivelsesnoterne, patch-status og funktionskontrollen for den konkret valgte målversion.

En managed-løsning til produktkataloger kan levere JSON-dokumenter og søgeindekser inden for den samme Redis 8-installation. Til telemetri kan Time Series levere en passende datamodel. Probabilistiske strukturer er nyttige, når applikationer kan arbejde med kontrollerede tilnærmelser, f.eks. for at genkende elementer, der formodes at være kendte, inden der foretages en dyrere backend-forespørgsel.

For en klassisk objektcache medfører dette dog ikke noget krav om nye datamodeller. WordPress-, webshop- eller PHP-applikationer bruger her ofte strenge, hashkoder og udløbstider. Integrationen kan lette standardiseringen af den leverede Redis-version, men retfærdiggør ikke søgeindekser, JSON-dokumenter eller vektordata uden konkrete anvendelseskrav og kapacitetsplanlægning.

Det afgørende er derfor tjenestegrænsen: En slank Cache-server kræver først og fremmest forudsigelig lageradministration og klart afgrænsede adgangsrettigheder. En data- eller søgetjeneste kræver desuden en datamodel, indeksopbygning, forespørgselsadfærd og driftskoncept. Redis 8 stiller disse byggesten til rådighed, men træffer ikke denne arkitektoniske beslutning på brugerens vegne.

Den fælles versionsstyring mindsker dermed først og fremmest kompleksiteten i release-styringen. Den erstatter ikke en kontrol af, om klienterne understøtter de anvendte kommandoer, eller om en eksisterende Redis-stack-implementering anvender særlige konfigurationer og indekser. Før en migrering skal sådanne afhængigheder indgå i den tekniske statusopgørelse.

Vurder fordelene ud fra Redis-anvendelsesscenariet

Om Redis 8 giver en praktisk merværdi, afhænger i højere grad af anvendelsessituationen end af versionsnummeret. Til objektcache, sessionshukommelse, køer, hastighedsbegrænsning og generel applikationscache er de grundlæggende Redis-funktioner stadig afgørende. Nye datatyper er her valgfri; applikationen behøver hverken at forstå eller anvende dem for at køre på Redis 8.

• Klassisk cache og sessioner: Fordelene ligger først og fremmest i en velvedligeholdt server og en kontrolleret drift; søge- eller vektorfunktioner ville i de fleste tilfælde udgøre en unødvendig kompleksitet.
• Køer og rate limiting: Redis-datastrukturer og atomare operationer er stadig centrale. Probabilistiske strukturer kan supplere særlige tilfælde, men giver ikke en generel, præcis tælling.
• Produktsøgning og dokumentdata: JSON og Redis Search kan understøtte en integreret tjeneste, når der reelt er behov for datamodeller, indekser og forespørgsler.
• Telemetri og tilnærmelsesanalyser: Tidsserier samt skitser og filtre passer til tidsbaserede måleværdier eller tilnærmelsesmetoder, forudsat at applikationerne tager højde for disse metoders begrænsninger.

I en normal objektcache bør driftsplanlægningen derfor Lagringsgrænser og prioritere udløbstider. Uden en fast grænse kan et voksende nøgleområde påvirke andre tjenester på værten negativt. Den rette eviction-strategi afhænger af, om der udelukkende findes overflødige cache-poster eller også fagligt relevante data i samme instans; de to typer bør så vidt muligt ikke blandes sammen.

For alle tilfælde er netværksbegrænsningen mere grundlæggende end en ny kommando. Redis anbefaler, at man ikke gør instanser direkte tilgængelige på internettet og begrænser Redis-porten til pålidelige klienter. TLS kan sikre klientforbindelser, replikering og cluster-bussen; ACL'er begrænser desuden kommandoer og tilgængelige nøglerum.

En Redis-opdatering er derfor især værd at overveje i forbindelse med rene cacher som en planlagt modernisering af version, vedligeholdelse og driftsmodel. Ved søgning, telemetri eller vektorapplikationer kan den integrerede funktionsbredde desuden være relevant. I begge tilfælde forbliver spørgsmålet det samme: Hvilke data, belastning og sikkerhedsgrænser skal denne enkelte instans rent faktisk håndtere?

Nye funktioner og ressourcebehov

Redis Open Source 8 samler funktioner, der tidligere typisk blev leveret via Redis Stack og dets komponenter: JSON-dokumenter, Redis Search, tidsserier samt probabilistiske datastrukturer. Derudover kommer vektorsæt, som i den første udgave, Redis 8.0.0, blev præsenteret som en forhåndsvisning. For hosting-tilbud reducerer den integrerede distribution antallet af komponenter, der skal vedligeholdes separat.

Fordelen opstår dog først ud fra en konkret servicemodel. JSON og Redis Search egner sig for eksempel til produktkataloger eller dokumentsøgninger, mens Time Series egner sig til tidsbaserede måleværdier. En klassisk objektcache kræver derimod ofte hverken dokumentforespørgsler eller indekser: Her er lagerkapacitet, udløbstider og en passende eviction-strategi de centrale driftsmæssige beslutninger.

For Bloom- og Cuckoo-filtre, Count-Min Sketch, Top-K og t-digest er den faglige begrænsning særlig vigtig: De understøtter sandsynligheds-, hyppigheds-, rang- eller kvantilskøn, men gemmer ikke nødvendigvis alle individuelle oplysninger nøjagtigt. Dermed kan de aflaste backend-søgninger eller omfattende analyser; de er imidlertid ikke egnede til afregningsrelevante eller revisionssikre enkeltværdier uden yderligere kontrol.

Klassisk rate limiting kræver derimod en bevidst valgt metode, f.eks. tællere, token bucket eller sliding window med passende Redis-strukturer og atomare processer. Probabilistiske strukturer kan i bedste fald supplere et specielt udformet, tilnærmelsesbaseret særtilfælde. De er ikke en generel erstatning for en præcis begrænsningslogik.

Vektorsæt imødekommer et andet behov. Redis gemmer vektorrepræsentationer og søger efter lignende elementer; JSON-attributter kan eventuelt inddrages til filtrering. Redis genererer ikke selve embeddings. Applikationer skal derfor hente dem fra en model eller en ekstern tjeneste, før semantisk søgning, anbefalinger eller hentning kan baseres på dem.

Dimensionering af vektorsæt på en realistisk måde

En Vektorsæt er beregnet til søgninger efter „lignende produkter“, „relevante dokumentuddrag“ eller semantisk søgning. Generel fuldtekstsøgning og vektorlighed er her to forskellige tilgange: Redis Search kan dække tekstfelter og forespørgsler, mens Vector Sets fastslår ligheder mellem vektorer. En almindelig webcache får ikke nogen funktionel merværdi alene gennem vektorer.

Funktionsplanlægningen skal fortsat være versionsspecifik. Redis 8.0.0 introducerede Vector Sets som en forhåndsvisning. Den aktuelle dokumentation beskriver datastrukturen og de tilhørende kommandoer, men fastslår ikke med tilbagevirkende kraft, at den oprindelige udgivelse var fuldt produktionsklar. Inden anvendelse skal man derfor kontrollere udgivelsesnoter og den konkret valgte Redis-versions adfærd med de nødvendige klienter.

I forbindelse med den første kapacitetsplanlægning angiver dokumentationen for 300 dimensioner et beregnet forbrug på 1.200 byte pr. FP32-vektor henholdsvis 300 byte pr. Q8-vektor. Ved 100.000 FP32-vektorer giver dette ca. 120 MB rådata; ved Q8 ca. 30 MB. Denne beregning beskriver udelukkende vektorkomponenten og er ikke en garanti for lagerbehovet for en produktiv instans.

Derudover kræver den HNSW-baserede søgestruktur hukommelse til grafforbindelser. Dertil kommer labels og valgfrie attributter; ligeledes kan fragmentering, replikater og persistente data ændre det faktiske ressourcebehov. Hvis man planlægger en højtilgængelig implementering, må man derfor ikke blot sidestille den rå størrelse med den tilgængelige arbejdshukommelse på en enkelt node.

Valget mellem FP32 og Q8 er således et spørgsmål om kvalitet og ressourcer, ikke en universel optimering. Det er fornuftigt at oprette et testmiljø med repræsentative vektorer, filterattributter og forespørgselsmønstre. Her kan man vurdere hukommelsesforbrug, svartider og resultatkvalitet for den konkrete kundesituation, inden kapaciteter eller klientgrænser fastlægges.

Kontrolleret forberedelse af Redis-opdatering

En Redis-opdatering Overgangen fra Redis Open Source 7.x eller Redis Stack til Redis 8 bør foregå som en planlagt overgang og ikke som en uovervåget pakkeopdatering på et produktionssystem. Først vælges en konkret målversion samt supportperiode. Derefter efterligner en staging-instans datamodellen, persistensen, klienterne og de relevante adgangsroller så realistisk som muligt.

Inden indgrebet bør teamet afklare, hvilke persistensfiler og sikkerhedskopier der rent faktisk hører til instansen, og hvordan gendannelsen foregår. Redis angiver, at opgraderingsprocessen omfatter sikkerhedskopiering, test og efterfølgende kontrol af version, dataadgang og klientforbindelser. En dokumenteret tilbageførsel kræver derfor ikke kun gamle pakker, men også en sporbar tilbageførselsvej for data og konfiguration.

Server- og persistensoplysninger samt den konfigurerede datastien er velegnede til en indledende gennemgang. Udfør følgende forespørgsler med en konto, der har tilladelse hertil, og gem resultatet uden for offentligt tilgængelige tickets eller logfiler, hvis det indeholder oplysninger om infrastrukturen.

redis-cli INFO server
redis-cli INFO persistence
redis-cli CONFIG GET dir
redis-cli INFO server | grep redis_version

Kommandoen SAVE nævnes i opgraderingsdokumentationen for et snapshot, men er ikke en standardkommando uden konsekvenser: Da det er en synkron proces, kan den påvirke driften afhængigt af datamængden og belastningen. Planlæg sikkerhedskopiering og vedligeholdelsesvinduer ud fra den anvendte persistensmodel. Til reproducerbare staging- og rollback-processer er det en fordel med en versionsstyret arbejdsgang med klart adskilte miljøer; artiklen passer godt hertil Webhosting med Git-understøttelse.

Kontroller ACL’er og klientadskillelse

En Managed Redis-tjeneste starter med en klar netværksgrænse: Redis-porten bør ikke være offentligt tilgængelig, men udelukkende være åben for pålidelige applikationsservere eller administrationsnetværk. TLS beskytter klientforbindelser, replikering og cluster-bussen under transmissionen. Disse foranstaltninger supplerer hinanden; TLS erstatter hverken en restriktiv firewall eller en velgennemtænkt adgangskontrol på serveren.

For flere kunder eller anvendelser er Adskillelse af klienter mere end et separat databasenummer. Egne instanser er nemmest at afgrænse. Hvis flere kunder deler en instans, skal ACL’er begrænse tilladte kommandoer og nøgleområder; derudover forhindrer lagerbegrænsninger, at en enkelt arbejdsbelastning opbruger kapaciteten for andre kunder. Nøglepræfikser er en del af reglen, men udgør ikke en selvstændig sikkerhedsgrænse.

Ved opdateringen af Redis til version 8 kræver især ACL-kontrollen særlig opmærksomhed. Kommandoer fra de nu integrerede komponenter er eksisterende kategorier som @read og @write tildelt. En hidtil bredt formuleret tilladelse kan derfor yderligere tillade f.eks. søgeforespørgsler eller skriveadgang til JSON. En syntaktisk gyldig ACL er derfor ikke automatisk fortsat fagligt set minimalt berettiget.

I praksis anbefales det at foretage en ACL-sammenligning: De eksporterede regler fra den hidtidige instans sammenlignes med de planlagte regler i Redis 8. For hver klientrolle bør teamet undersøge, hvilke kommandoer der rent faktisk er nødvendige, hvilke nøglepræfikser der forbliver tilgængelige, og om en nyarvet kategori indebærer uønskede rettigheder. Det afgørende er sammenligningen af de faktiske rettigheder, ikke blot konfigurationsteksten.

Derefter oprettes der målrettede test for hver rolle: En webcache-klient må for eksempel læse og skrive sine tildelte cachenøgler, men må ikke anvende fremmede præfikser eller administrationskommandoer. Der gælder særskilte test for søge- eller JSON-applikationer. Sådanne rollebaserede kontroller gør ændringer sporbare, uden at man skal fastlægge en universel ACL-skabelon for forskellige kundearkitekturer.

Drift, overvågning og fejlfinding

I driften anbefales det at overvåge hukommelsesudnyttelse, evictions, latenstider, klientforbindelser, persistens og replikering hver for sig. Disse værdier afspejler forskellige flaskehalse og bør derfor vurderes i sammenhæng med den pågældende servicemodel. En stigning i evictions er ikke nødvendigvis tegn på en Redis-fejl, men er en anledning til at kontrollere hukommelsesgrænser, udløbstider og datamodellen.

Søgeindekser og vektorsæt må ikke medregnes i en måleværdi sammen med en almindelig objektcache. Ud over nøglemængden tæller indeks- og grafhukommelse, attributter samt den respektive forespørgselsbelastning med. For vektorer kommer labels, forbindelser, fragmentering, replikering og persistens oven i behovet for rådata. At dimensionere en instans udelukkende på baggrund af vektorværdierne undervurderer derfor det reelle ressourcebehov.

Redis 8 introducerer en ny implementering af I/O-threading; indstillingen io-threads er dog ikke en universel løsning til at øge ydeevnen. Heller ikke forbedringer i replikeringen er grundlag for et generelt løfte om gennemstrømning. CPU-kerner, netværk, persistens, kommandosammensætning og klientadfærd er med til at afgøre, om en ændring hjælper. Derfor hører konfigurationsvarianter hjemme i et produktionsnært testmiljø med sin egen belastningsprofil.

Efter en opgradering er uidentificerede klientproblemer ofte mere sigende end rene servermålinger. Teamet bør kontrollere forbindelser, autentificering, anvendte kommandoer og fejlmeddelelser ved hjælp af de faktiske klientbiblioteker. En velafprøvet genoprettelsesprocedure er lige så vigtig: En eksisterende sikkerhedskopi mindsker først risikoen, når data og applikation fungerer efter kontrol efter gendannelsen.

Ved alarmering er det nyttigt at anvende forskellige tærskelværdier alt efter tjenesteklasse. En cache kan bevidst tolerere evictioner, mens disse kan medføre datatab i forbindelse med sessioner eller køer. Søge- og vektor-workloads kræver desuden overvågning af deres hukommelsesudvikling og forespørgselsforsinkelser. Artiklen giver baggrundsinformation om observabilitet, skalering og ressourceplanlægning Hosting-tendenser 2026.

I forbindelse med fejlfinding bør ændringer i datamodellen, klientversionen, lagergrænsen og persistenskonfigurationen tidsmæssigt knyttes til målingerne. På den måde kan man skelne mellem, om en latenstop for eksempel falder sammen med en ny søgebelastning, en stigning i antallet af forbindelser eller en persistensfase. Denne sammenkædning er mere pålidelig end antagelsen om, at enhver afvigelse er en følge af Redis-opdateringen.

Gendannelse som revisionsundersøgelse En sikkerhedskopi i sig selv er ikke ensbetydende med, at systemet kan genstartes. I opgraderingsvejledningen anbefales det at gennemføre en kontrolleret øvelse af sikkerhedskopiering og opgradering samt derefter at kontrollere dataadgangen og klientforbindelserne.

At træffe beslutninger om licenser og produkter

Valget af licens i Redis 8 er en produktbeslutning, ikke blot et punkt i installationsvejledningen. Redis Open Source kan bruges under RSALv2, SSPLv1 eller AGPLv3. Hvilken mulighed der passer bedst til en intern instans, en kundedrift eller et offentligt tilbudt Managed Redis-produkt, afhænger af den konkrete implementeringsform og de dermed forbundne forpligtelser.

RSALv2 begrænser blandt andet kommercialisering eller tilvejebringelse af softwarefunktionaliteten som en managed service til tredjeparter. SSPLv1 og AGPLv3 indeholder copyleft-krav, der kan blive relevante i forbindelse med levering af tjenester henholdsvis netværksadgang. Denne korte beskrivelse erstatter ikke juridisk rådgivning: Inden prisfastsættelse, indgåelse af aftaler eller produktlancering bør den konkrete arkitektur gennemgås juridisk.

Produktdifferentiering er lige så vigtig. Redis Open Source 8 betegner serverlinjen med dens integrerede datastrukturer og forespørgselsfunktioner. Redis Software er derimod en kommerciel produktlinje med egen udgivelsesdokumentation og support til flere Redis-databaseversioner. Man må ikke udlede heraf, at alle de der beskrevne klynge-, administrations- eller højtilgængelighedsfunktioner er en del af en almindelig open source-installation.

Hverken Valkey eller andre forks er Redis 8-varianter. Hvis man betragter dem som alternativer, skal man selv undersøge de kommandoer, de understøtter, deres driftsmodel, licens og migrationsvej. En lignende protokolgrænseflade eller en fælles historisk oprindelse er ikke tilstrækkeligt til at udlede løfter om funktionalitet og kompatibilitet for applikationer eller administrerede tilbud.

En velovervejet beslutning tager højde for fem spørgsmål: Hvilken konkret Redis-version passer til den planlagte supportperiode? Kræver arbejdsbyrden faktisk søgning, tidsserier eller vektorer? Er driftsmodellen dækket med isolation, sikkerhedskopier og overvågning? Er ACL’er og klienter blevet kontrolleret? Og er Licensprøve er der indgået en aftale om den tilbudte tjenesteform? Det er først samspillet mellem disse punkter, der gør en Redis-opdatering til et pålideligt hostingtilbud.