Hvad er Redis: En komplet guide til anvendelser, fordele og eksempler

Informatic Digital » udvikling » Hvad er Redis: En komplet guide til anvendelser, fordele og eksempler

Hvis du nogensinde har haft brug for, at din applikation skulle køre som en raket, har du sikkert hørt om Redis. Denne teknologi fungerer som et in-memory datasystem, der tilbyder meget lave latenser og næsten øjeblikkelige svar, ideelt når hastighed er den absolutte prioritet.

Redis er mere end blot en cache; det er en nøgle-værdi NoSQL-database med flere datastrukturer og integrerede værktøjer. Oprindeligt lanceret i 2009 og skrevet i C, stammer navnet fra Remote Dictionary Server . I dag kan den prale af et meget aktivt økosystem, klienter til næsten ethvert programmeringssprog og robuste persistens- og replikeringsfunktioner.

Hvad er Redis, og hvad bruges det til?

Redis er en in-memory lagringsmotor, der arbejder med nøgle-værdi-par og avancerede strukturer. Ved at operere i RAM reducerer den de flaskehalse, der er typiske for diskadgang , hvilket gør den perfekt til brugsscenarier, hvor ekstrem hastighed er nødvendig: caches til tunge forespørgsler, brugersessioner, realtidsbeskeder, online spil, dashboards med streamingdata og mere.

I mange projekter bruges den som et cachelag foran traditionelle databaser , hvor den lagrer gentagne resultater for at undgå kontinuerlig genberegning eller genforespørgsel. Den bruges også som en database i sig selv, når streng holdbarhed ikke er et krav, eller når dens persistens er konfigureret til at sikre, at data gemmes på disk.

Dens klient/server-arkitektur, netværksgrænseflade og lette design gør det nemt at implementere og oprette forbindelse fra flere værter. Derudover tilbyder den asynkron master-til-replika (masteren fortsætter med at fungere under replikering), hvilket hjælper med at skalere læsninger og forbedre tilgængeligheden.

Nøglefunktioner

Redis' største styrke er, at alt ligger i hovedhukommelsen. Dette eliminerer diskadgang under den kritiske sti og giver ekstremt hurtige læse-/skriveoperationer . Derudover kan hver streng nå op til 512 MB, med understøttelse af binære data, og inkluderer strukturer som lister, sæt, sorterede sæt, hashes, HyperLogLog, bitmaps og streams.

Redis implementerer atomare operationer på højt niveau på serversiden på disse strukturer. Dette giver dig mulighed for at udføre unioner, skæringspunkter eller differenser på sæt, ændre understrenge eller øge og mindske heltal og flydende tal uden kapløbsbetingelser.

Det inkluderer værktøjer, der accelererer udvikling og forenkler almindelige mønstre: Pub/Sub til publicering og abonnement på kanaler (ideelt til beskeder og notifikationer i realtid), nøgler med TTL til automatisk udløb, atomtællere til metrikker og samtidighedskontrol samt integreret understøttelse af Lua-scripts til serversidelogik fra version 2.6.

En anden stærk fordel er dens kompatibilitet med moduler. Redis-moduler udvider funktioner som JSON-dokumenter , tidsserier og søgning , hvilket gør det til et alsidigt system, der går langt ud over simpel nøgle-værdi-parring.

Historie, licenser og udvikling

Redis blev skabt i 2009 af Salvatore Sanfilippo for at forbedre latensen af ​​et produkt kaldet LLOGG. Dets succes var øjeblikkelig, og i 2010 ansatte VMware Sanfilippo til at lede projektet på fuld tid ; Pieter Noordhuis kom til kort efter. Mellem 2013 og 2015 blev det sponsoreret af Pivotal og senere af Redis Labs.

Siden version 2.6 har serveren integreret en Lua-fortolker, der muliggør udførelse af scripts direkte i Redis med atomicitet og minimerer klient-server round-trip latency. Med hensyn til licensering er den distribueret under en dobbelt RSALv2- og SSPLv1- model.

Datamodel og operationer

Redis bruger en global ordbog, der knytter nøgler til værdier. I modsætning til simplere nøgle-værdi-løsninger kan værdier være af forskellige typer. Typen bestemmer de tilgængelige kommandoer og de atomare operationer, du kan udføre på disse data.

Redis-strengtypen er "binærsikker": den kan indeholde tekst, heltal, flydende tal eller rå binære data, såsom et JPEG-billede eller et serialiseret objekt. Du kan operere på dele af strengen, ændre specifikke bits eller bruge den som en tæller med forøgelser/formindskelser.

Lister giver dig mulighed for at administrere køer eller stakke, sæt og ordnede sæt bruges til medlemskab og rangering efter score, og hashes gemmer felt-værdi-kort, hvilket er meget nyttigt til gruppering af attributter for et objekt . HyperLogLog bruges til omtrentlige kardinalitetstællere med meget lidt hukommelse, og streams faciliterer hændelsesflows med grupperet forbrug.

Derudover tilbyder Redis transaktioner (MULTI/EXEC), så du kan gruppere flere operationer for at udføre dem sekventielt og atomart . Kombineret med Lua kan du pålideligt indkapsle kompleks server-side logik.

Persistens: snapshots og AOF

Redis kan udelukkende fungere i hukommelsen, men understøtter også diskpersistens for at balancere ydeevne og holdbarhed. Med snapshots (RDB) tager det periodiske snapshots af datasættet og gemmer dem asynkront, hvilket resulterer i minimal påvirkning af responstiden.

Den anden mulighed er AOF (journaling), som registrerer hver skriveoperation til en fil. Denne tilstand giver en finere og mere konfigurerbar holdbarhed: `appendfsync=always` gennemtvinger synkronisering ved hver ændring (maksimal sikkerhed, lavere ydeevne), og `appendfsync=everysec` synkroniserer hvert sekund (god balance).

Om nødvendigt kan du også udløse en manuel GEM for at fremtvinge et øjebliksbillede med det samme. I tilfælde af et totalt maskinfejl vil du typisk miste højst en lille mængde data, afhængigt af den valgte synkroniseringspolitik.

I ældre versioner var brugen af ​​"virtuel hukommelse" tilladt fra og med version 2.4, men den tilgang er nu forældet. I dag anbefales det at vælge mellem RDB, AOF eller en kombination af begge , og justere konfigurationen i henhold til datakritikalitet og ønsket ydeevne.

Replikering og høj tilgængelighed

Redis implementerer asynkron master-replika-replikering. Det betyder, at skrivninger accepteres på masteren, og replikaer synkroniseres uden at blokere den, hvilket holder tjenesten operationel under synkroniseringer . En master kan have flere replikaer, og til gengæld kan en replika kædes sammen som masteren for en anden replika, hvilket danner en trætopologi.

Replikering er meget nyttig til skalering af læseoperationer og til redundans. Nogle konfigurationer tillader skrivning til replikaer, selvom dette kan føre til uoverensstemmelser, hvis det ikke kontrolleres korrekt. Som standard bruges replikaer normalt skrivebeskyttet for at opretholde konsistens.

Placering af replikaer i nærheden af ​​brugerne reducerer den opfattede latenstid. Med orkestrerings- og sentinel-/klyngeværktøjer kan høj tilgængelighed og automatisk failover opnås for at minimere nedetid i tilfælde af masterfejl.

Klient/server-arkitektur og økosystem

Redis-serveren stiller en simpel protokol til rådighed, som klienter på forskellige sprog opretter forbindelse til. Du kan interagere med dens officielle CLI (redis-cli) til test, administration eller hurtig scripting, eller du kan integrere et bibliotek i din applikation.

Der er klienter til ActionScript, C, C++, C#, Java, Go, Python, PHP, Ruby, Scala, JavaScript (inklusive server-side Node.js), R, Erlang, Haskell, Lua, Objective-C, Perl, Common Lisp, Smalltalk, Tcl, Io, haXe, Pure Data og mere. Denne brede understøttelse gør det nemt at implementere det på tværs af næsten enhver stak.

Virkelige anvendelsesscenarier og praktiske eksempler

Et meget almindeligt eksempel er et online ejendomsmæglerfirma: en ejendomsannonce med pris, faciliteter og antal værelser ændrer sig næsten ikke. Uden caching kræver hvert besøg gentagne forespørgsler og beregninger. Med Redis gemmes objektet efter den første indlæsning med en nøgle (f.eks. property_4056 ) og en TTL på f.eks. en måned. Efterfølgende besøg læses fra hukommelsen og undgår adgang til databasen.

Det er også almindeligt at cache tunge rapportresultater , administrere godkendte sessioner, opbygge live-rangeringer med sorterede sæt eller bruge Pub/Sub som en letvægtsmeddelelseskanal mellem tjenester.

I en test med en fejltabel med 16.000 rækker blev tiden målt for: 1) at forespørge databasen, 2) at gemme samlingen i Redis og 3) at læse fra Redis. Resultatet var slående: hentning fra Redis var 26 gange hurtigere end fra databasen. Disse sammenligninger fremhæver ofte den reelle indvirkning på brugeroplevelsen og infrastrukturomkostningerne.

Redis vs. Memcached

Begge teknologier bruges til in-memory caching, men der er bemærkelsesværdige forskelle. Redis tilbyder flere datatyper (lister, sæt, hashes osv.), valgfri diskpersistens , Pub/Sub, Lua-scripts, transaktioner og moduler for at udvide dens muligheder. Memcached fokuserer derimod på en simpel in-memory nøgle-værdi-model uden persistens.

Med hensyn til rå ydeevne er begge meget hurtige; Redis har en tendens til at udmærke sig i scenarier med komplekse strukturer og atomare server-side operationer. Hvis du kun har brug for en meget simpel og ultralet cache, kan Memcached være tilstrækkeligt , men når du leder efter mere funktionalitet og fleksibilitet, er Redis normalt den bedste løsning.

Administrerede vs. selvadministrerede tjenester (Redis og Valkey)

Du kan selv implementere Redis eller Valkey eller vælge en administreret cloud-tjeneste. Selvadministration giver dig fuld kontrol, men skalerbarhed og vedligeholdelse er dit ansvar (tilføjelse af noder, opdateringer, sikkerhed, backups, overvågning).

En administreret tjeneste reducerer den driftsmæssige byrde: nemmere skalering, høj tilgængelighed og problemfri opdateringer. Dette resulterer typisk i lavere samlede ejeromkostninger og giver teamet mulighed for at fokusere mere på datamodellering og forretningsfunktioner i stedet for platformopgaver.

Integrerede værktøjer: Pub/Sub, TTL, tællere og Lua

Med Pub/Sub kan du udsende beskeder i kanaler og få flere abonnenter til at modtage dem med det samme, hvilket er perfekt til chats, notifikationer og koordinering mellem mikrotjenester. Det er et simpelt og effektivt mønster.

Time-to-live (TTL)-nøgler giver dig mulighed for at "selvrense" midlertidige data: sessioner, tokens, udløbne forespørgselsresultater osv. Dette forhindrer dig i at fylde databasen med forældede oplysninger og forenkler udløbslogikken.

Atomtællere er fantastiske til metrikker, hastighedsbegrænsning, køer eller ethvert tilfælde, hvor du har brug for at lægge sammen/subtrahere sikkert i samtidige miljøer.

Endelig giver Luas indlejrede understøttelse dig mulighed for at køre scripts tæt på dataene med atomicitet. Dette reducerer netværksrejse og giver dig mulighed for at udføre komplekse operationer i et enkelt trin , hvilket forbedrer konsistens og ydeevne.

Ofte stillede spørgsmål

Hvad bruges Redis til? Til at accelerere applikationer med in-memory caches, sessioner, realtidsrangeringer, letvægtsmeddelelser med Pub/Sub og som en NoSQL-database, når latenstid er kritisk, eller persistens er konfigureret.

Hvorfor er Redis så hurtig? Fordi data ligger i RAM, hvilket eliminerer diskadgang på den kritiske sti og tilbyder atomare serversideoperationer; desuden er dens protokol let og effektiv.

Kan den bruges som en database? Ja. Det er en in-memory NoSQL-database med persistensmuligheder (RDB og AOF). Afhængigt af din konfiguration kan du prioritere ydeevne eller holdbarhed eller kombinere begge dele.

Sprogstøtte

Der findes veludviklede klienter til stort set alt: Python (redis-py), Java (Jedis), Node.js (ioredis), C#/.NET (StackExchange.Redis), PHP (phpredis), Go (go-redis), Ruby (redis-rb) og mange flere. Denne variation sikrer problemfri integration med din eksisterende stak.

Redis har etableret sig som "wild card" til løsning af performance- og realtidsproblemer i de fleste moderne arkitekturer: det kombinerer lynhurtig drift, omfattende datastrukturer, konfigurerbar persistens, replikering og et sæt praktiske værktøjer, der, når de bruges korrekt, gør en forskel i dine brugeres oplevelse.