Hvis du tænker på en cacheløsning på serversiden, er det sandsynligt, at du har hørt om Redis eller Memcached.
Begge dele Redis og Memcached er:
Hvad er forskellen mellem Memcached og Redis?
Memcached og Redis gemmer begge data i hukommelsen for at forbedre applikationshastigheden, men de imødekommer forskellige behov.
Men lad os undersøge mere detaljeret forskellene i denne artikel. Baseret på et projekt, vi har udviklet til en klient, vil jeg dække hvordan de håndterer datalagring, skalerbarhed og hvilken klarer sig bedre i betragtning af visse scenarier. Men først, lad os starte med det grundlæggende.
Redis, som betyder Remote Dictionary Server, blev oprettet i 2009 af Salvatore Sanfilippo for at forbedre skalerbarheden af webloganalysatoren, som hans italienske opstart byggede. Den første prototype blev skrevet i Tcl og senere transskriberet til C. Da Sanfilippo besluttede at open source projektet, begyndte det at få noget trækkraft. Giganter som GitHub og Instagram var nogle af de første virksomheder, der vedtog det.
Memcached blev oprettet lidt tidligere, i 2003, af Brad Fitzpatrick til hans LiveJournal-websted. Det blev oprindeligt udviklet i Perl og derefter oversat til C. Det bruges af nogle af de største virksomheder derude som Facebook, Youtube og Twitter.
Redis har fem datatyper:
Redis understøtter datatypeoperationer. Det betyder, at du kan få adgang til eller ændre dele af et dataobjekt uden at skulle indlæse hele objektet på et applikationsniveau, ændre det og derefter gemme den opdaterede version igen. Redis bruger en indkapslet version af malloc/free memory management, hvilket er en enklere tilgang sammenlignet med Memcached Slab-mekanismen, som jeg vil forklare nedenfor. Redis understøtter nøgler med en maksimal størrelse på 512 MB og værdier op til 512 MB. Denne grænse er pr. element på aggregerede datatyper (lister og sæt).
I modsætning til Redis, Memcached har ingen datatyper, da det gemmer strenge indekseret af en strengnøgle. Sammenlignet med Redis, det bruger mindre overhead-hukommelse. Den er også begrænset af mængden af hukommelse på sin maskine, og hvis den er fuld, begynder den at rense værdier på en mindst nylig brugt ordre. Den bruger en allokeringsmekanisme kaldet Slab, som segmenterer den tildelte hukommelse i bidder af forskellige størrelser og gemmer nøgleværdi-dataposter af den tilsvarende størrelse. Dette løser hukommelsesfragmenteringsproblemet. Memcached understøtter nøgler med en maksimal størrelse på 250B og værdier op til 1MB. Men bemærk, at det kun er standard og kan ændres ved opstart ved at øge den maksimale pladestørrelse.
Lad os tage det enkle eksempel på at bruge en cache til at gemme et brugersessionsobjekt.
Hvis vi bruger Memcached til at ændre et enkelt felt i objektet, skal strengen indlæses, deserialiseres, objektfeltet redigeres, serialiseres og gemmes. Hvis vi bruger Redis, kan hash-datatypen bruges. Det giver adgang til hvert felt i hashen individuelt, så enhver CRUD (oprette, læse, opdatere, slette) operation kan udføres på hver enkelt af dem. Dette gør det muligt at afbøde behovet for at gøre det på applikationsniveau. Det fører til effektivitet, når det kræver mindre I/O-operationer.
Siden Redis er overvejende enkelttrådet og har indbygget understøttelse af klyngedannelse, det vokser godt vandret.
Redis clustering fungerer med en master/slave arkitektur. For hver masternode er der to slave-noder til redundans, derfor, hvis masteren fejler, promoverer systemet automatisk en af slaverne som den nye master. Denne form for skalerbarhed kommer med ulempen ved vedligeholdelseskompleksitet. Det er sværere at vedligeholde flere noder, der kører synkront end en enkelt.
Memcached skaleres let lodret, som det er multitrådet. De eneste krav er at give det flere kerner og mere hukommelse. Det kan også skaleres vandret på klientsiden ved implementering af en distribueret algoritme. Dette kommer med ulempen ved at være mere kompleks at implementere, mens Redis har det ud af kassen.
Når man beslutter, om man skal bruge Redis eller Memcached, er en stor forskel mellem disse to datapersistens.
Mens Redis er et datalager i hukommelsen (for det meste) og det er ikke ustabilt, Memcached er en cache i hukommelsen og det er ustabilt.
Også Memcached er begrænset til LRU's (mindst nyligt anvendte) udsættelsespolitik mens Redis understøtter seks forskellige politikker:
Redis understøtter vedholdenhed, derfor kaldes det et datalager på to forskellige måder:
Disse filer håndteres af en underordnet proces, og dette er en nøglefaktor i beslutningen om, hvilken form for vedholdenhed der skal bruges.
Hvis datasættet, der er gemt i Redis, er for stort, vil RDB-filen tage nogen tid at blive oprettet, hvilket har indflydelse på responstiden. På den anden side vil det være hurtigere at indlæse ved opstart sammenlignet med AOF-loggen.
Den AOF-log er bedre, hvis tab af data slet ikke er acceptabelt, da det kan opdateres ved hver kommando. Det har heller ingen korruptionsproblemer, da det er en fil, der kun er tilføjet. Det kan dog vokse meget større end et RDB-snapshot.
1. Sessionscaching i webapplikationer: Redis kan gemme brugersessionsdata til webapplikationer, hvilket er særligt nyttigt for platforme med et stort antal samtidige brugere. For eksempel kan et e-handelswebsted bruge Redis til hurtigt at hente brugersessioner uden at ramme databasen, hvilket fremskynder brugeroplevelsen under login- og betalingsprocesser.
2. Analyse i realtid: Redis datastrukturer som sorterede sæt og hashes kan bruges til at implementere realtidsanalysedashboards. For eksempel kan en social medieplatform bruge Redis til at spore og vise antallet af aktive brugere eller indlæg, der trender i realtid.
3. Message Queuing og Chat-applikationer: Redis pub/sub-funktioner muliggør beskedkøsystemer i realtid. Det kan bruges til at opbygge chatapplikationer, hvor meddelelser skal leveres med det samme til forskellige abonnenter.
4. Leaderboards og optælling: Spil og sociale platforme bruger ofte Redis til at administrere leaderboards på grund af dets evne til at håndtere høje skrive- og læsehastigheder. For eksempel kan en online spilplatform bruge Redis til at opdatere og vise spillerplaceringer i realtid.
5. Fuldsides cache (FPC): Redis kan bruges som en FPC til at gemme output af databaseforespørgsler og reducere belastningen på databasen. For eksempel kan et indholdsstyringssystem (CMS) bruge Redis til at cache sider og betjene dem hurtigt uden at regenerere dem på hver anmodning.
1. Enkel strengcachelagring: Memcached er ideel til små og mellemstore websteder, der har brug for et simpelt cachelag til strenge. For eksempel kan et blogwebsted bruge det til at cache resultaterne af databaseforespørgsler til blogindlæg og servere dem hurtigere til besøgende.
2. Cachelagring af databaseforespørgselsresultat: Memcached kan bruges til at cache resultaterne af almindeligt tilgængelige databaseforespørgsler, hvilket reducerer databasebelastningen. Et online katalogsystem kunne bruge det til at cache produktlister og detaljer.
3. Cachelagring af HTML-fragmenter: Websteder med statiske HTML-fragmenter, der er dyre at generere, kan bruge Memcached til at gemme disse fragmenter. For eksempel kan et nyhedswebsted gemme artikeluddrag på hjemmesiden for at forbedre indlæsningstiderne.
4. API-hastighedsbegrænsning: Memcacheleds atomiske inkrement- og dekrementeringsoperationer kan bruges til at implementere API-hastighedsbegrænsning. En RESTful API kunne bruge Memcached til at spore antallet af anmodninger fra en bruger inden for en given tidsramme og forhindre misbrug.
5. Sessionsbutik: I lighed med Redis kan Memcached bruges til at gemme brugersessioner, skønt uden vedholdenhed. Dette er velegnet til applikationer, hvor sessionsdata er forbigående og kan gå tabt uden væsentlig påvirkning, såsom i statsløse mikrotjenester.
Det afhænger bestemt af kravene.
Redis er helt sikkert mere fleksibel og kraftfuld, men Memcached tjener nogle formål meget godt og opnår i nogle tilfælde bedre ydeevne. Ved at være flertrådet har det fordele, især når man arbejder med big data.
Redis understøtter dataoperationer takket være dens datatyper, som kan fremskynde sagsscenarier ved at reducere netværkets I/O-tællinger og datastørrelser. Disse dataoperationer er lige så tunge som et get or set.
Ved Imaginær sky Vi har brugt begge i Mange forskellige kunders projekter. I en, som jeg var involveret i, var vi nødt til at vælge mellem de to muligheder. Først gik vi med Memcached baseret på dets enkelhed, brugervenlighed, nem opsætning, og vi havde simpelthen brug for en cache, så vedholdenhed var ikke et krav. Selvom, efter nogle tests, vi besluttede at bytte til Redis på grund af fordelene ved at have datatyper.
I dette projekt var datatypeoperationerne en fordel for den slags data, der skulle gemmes. Redis giver også en kommando til at søge efter nøgler, der matcher et mønster sammen med mange andre nyttige kommandoer til at håndtere nøgler. Dette var noget virkelig nyttigt for os og et centralt punkt i beslutningen om at migrere til Redis.
Med hensyn til migrationen var det meget let at udføre, da Redis understøtter de fleste af de kommandoer, som Memcached gør. Hvis vi havde omvendt ruten og besluttet at migrere fra Redis til Memcached, ville det have været meget sværere, da Memcached ikke har nogen datatyper. Enhver Redis-datatypekommando ville være blevet oversat til mange kommandoer sammen med en vis databehandling imellem dem for at opnå det samme resultat.
Når det kommer til at træffe en beslutning, kan vi ikke rigtig sige, at den ene er bedre end den anden, da det hele afhænger af projektkravene. Baseret på vores erfaring er det dog vigtigt at overveje fordele og ulemper lige fra starten for at undgå ændringer og migrationer under projektet.
Webudvikler på Imaginær sky, der er begejstret for Node.js og alt relateret til back-end udvikling.
CEO @ Imaginary Cloud og medforfatter af bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i denne rækkefølge).
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
