kontakta oss

Om du funderar på en cachelösning på serversidan är det troligt att du har hört talas om Redis eller Memcached.
Vad är skillnaden mellan Memcached och Redis?
Memcached och Redis lagrar båda data i minnet för att förbättra applikationshastigheten, men de tillgodoser olika behov.
Men låt oss utforska mer detaljerat skillnaderna i den här artikeln. Baserat på ett projekt som vi utvecklat för en kund kommer jag att täcka hur de hanterar datalagring, skalbarhet och vilken presterar bättre med tanke på vissa scenarier. Men först, låt oss börja med grunderna.
Redis, vilket betyder Remote Dictionary Server, skapades 2009 av Salvatore Sanfilippo, för att förbättra skalbarheten hos webbloganalysatorn som hans italienska startup byggde. Den första prototypen skrevs i Tcl och transkriberades senare till C. När Sanfilippo bestämde sig för att öppna källkoden började det få lite dragkraft. Jättar som GitHub och Instagram var några av de första företagen som antog det.
Memcached skapades lite tidigare, 2003, av Brad Fitzpatrick för sin LiveJournal-webbplats. Det utvecklades ursprungligen i Perl och översattes sedan till C. Det används av några av de största företagen där ute som Facebook, Youtube och Twitter.
Redis har fem datatyper:
Redis stöder datatypoperationer. Det innebär att du kan komma åt eller ändra delar av ett dataobjekt utan att behöva ladda hela objektet till en programnivå, ändra det och sedan lagra den uppdaterade versionen igen. Redis använder en inkapslad version av malloc/free memory management, vilket är ett enklare tillvägagångssätt jämfört med Memcached Slab -mekanismen, som jag kommer att förklara nedan. Redis stöder nycklar med en maximal storlek på 512 MB och även värden upp till 512 MB. Denna gräns gäller per element för aggregerade datatyper (listor och uppsättningar).
Till skillnad från Redis, Memcached har inga datatyper, eftersom den lagrar strängar indexerade av en strängnyckel. Jämfört med Redis, det använder mindre overhead minne. Dessutom begränsas den av mängden minne på sin maskin och, om den är full, kommer den att börja rensa värden på en minst nyligen använd order. Den använder en allokeringsmekanism som kallas Slab, som segmenterar det tilldelade minnet i bitar av olika storlekar och lagrar nyckelvärdesdataposter av motsvarande storlek. Detta löser minnesfragmenteringsproblemet. Memcached stöder nycklar med en maximal storlek på 250B och värden upp till 1MB. Men notera att det bara är standard och kan ändras vid start genom att öka den maximala plattstorleken.
Låt oss ta det enkla exemplet på att använda en cache för att lagra ett användarsessionsobjekt.
Om vi använder Memcached för att ändra ett enda fält i objektet måste strängen laddas, deserialiseras, objektfältet redigeras, serialiseras och lagras. Om vi använder Redis kan hash-datatypen användas. Det ger åtkomst till varje fält i hashen individuellt så att alla CRUD (skapa, läsa, uppdatera, radera) operationer kan utföras på var och en av dem. Detta gör det möjligt att mildra behovet av att göra det på applikationsnivå. Det leder till effektivitet när det kräver mindre I/O-operationer.

Sedan Redis är övervägande enkelgängad och har inbyggt stöd för klustring, det växer bra horisontellt.
Redis clustering fungerar med en master/slave arkitektur. För varje huvudnod finns det två slavnoder för redundans, därför, om mastern misslyckas, så befordrar systemet automatiskt en av slavarna som den nya mastern. Denna typ av skalbarhet kommer med nackdelen med underhållskomplexitet. Det är svårare att upprätthålla flera noder som körs synkront än en enda.
Memcached skalas enkelt vertikalt, som det är flertrådigt. De enda kraven är att ge det fler kärnor och mer minne. Det kan också skalas horisontellt, på klientsidan, genom implementering av en distribuerad algoritm. Detta kommer med nackdelen att vara mer komplex att implementera medan Redis har det ur lådan.
När man bestämmer sig för om man ska använda Redis eller Memcached är en stor skillnad mellan dessa två datapersistens.
Medan Redis är ett datalager i minnet (mestadels) och det är inte flyktigt, Memcached är en cache i minnet och det är flyktigt.
Också Memcached är begränsad till LRU:s (minst nyligen använda) utvisningspolicy medan Redis stöder sex olika policyer:
Redis stöder uthållighet, därför kallas det ett datalager, på två olika sätt:
Dessa filer hanteras av en underordnad process och detta är en nyckelfaktor för att bestämma vilken typ av uthållighet som ska användas.
Om datauppsättningen som lagras i Redis är för stor tar RDB-filen lite tid att skapas, vilket påverkar svarstiden. Å andra sidan blir det snabbare att ladda vid uppstart jämfört med AOF-loggen.
Den AOF-logg är bättre om dataförlust inte alls är acceptabelt, eftersom det kan uppdateras vid varje kommando. Det har inte heller några korruptionsproblem eftersom det är en fil med bara tillägg. Det kan dock växa mycket större än en RDB-ögonblicksbild.
1. Sessionscachning i webbapplikationer: Redis kan lagra användarsessionsdata för webbapplikationer, vilket är särskilt användbart för plattformar med ett stort antal samtidiga användare. Till exempel kan en e-handelswebbplats använda Redis för att snabbt hämta användarsessioner utan att träffa databasen, vilket påskyndar användarupplevelsen under inloggnings- och utcheckningsprocesser.
2. Analys i realtid: Redis datastrukturer som sorterade uppsättningar och hascher kan användas för att implementera realtidsanalysinstrumentpaneler. Till exempel kan en social medieplattform använda Redis för att spåra och visa antalet aktiva användare eller inlägg som trender i realtid.
3. Meddelandekö- och chattprogram: Redis pub/sub-funktioner möjliggör system för meddelandeköer i realtid. Det kan användas för att bygga chattapplikationer där meddelanden måste levereras direkt till olika prenumeranter.
4. Leaderboards och räkning: Spel och sociala plattformar använder ofta Redis för att hantera topplistor på grund av dess förmåga att hantera höga skriv- och läshastigheter. Till exempel kan en onlinespelplattform använda Redis för att uppdatera och visa spelarrankningar i realtid.
5. Helsidescache (FPC): Redis kan användas som en FPC för att lagra utdata från databasfrågor och minska belastningen på databasen. Till exempel kan ett innehållshanteringssystem (CMS) använda Redis för att cachelagra sidor och servera dem snabbt utan att regenerera dem på varje begäran.
1. Enkel strängcachning: Memcached är perfekt för små och medelstora webbplatser som behöver ett enkelt cachelager för strängar. Till exempel kan en bloggwebbplats använda den för att cacha resultaten av databasfrågor för blogginlägg och servera dem snabbare till besökare.
2. Cachelagring av databasfrågeresultat: Memcached kan användas för att cache resultaten av vanliga databasfrågor, vilket minskar databasbelastningen. Ett online-katalogsystem kan använda det för att cache produktlistor och detaljer.
3. Cachelagring av HTML-fragment: Webbplatser med statiska HTML-fragment som är dyra att generera kan använda Memcached för att lagra dessa fragment. Till exempel kan en nyhetswebbplats cache artikelutdrag på hemsidan för att förbättra laddningstiderna.
4. API-hastighetsbegränsning: Memcacheleds atomöknings- och dekrementeringsoperationer kan användas för att implementera API-hastighetsbegränsning. Ett RESTful API kan använda Memcached för att spåra antalet förfrågningar från en användare inom en viss tidsram, vilket förhindrar missbruk.
5. Sessionslagring: I likhet med Redis kan Memcached användas för att lagra användarsessioner, men utan uthållighet. Detta är lämpligt för applikationer där sessionsdata är övergående och kan gå förlorade utan betydande påverkan, till exempel i statslösa mikrotjänster.
Det beror verkligen på kraven.
Redis är säkert mer flexibel och kraftfull, men Memcached tjänar vissa syften mycket bra och i vissa fall uppnår bättre prestanda. Genom att vara flertrådad har det fördelar, särskilt när man arbetar med big data.
Redis stöder datatoperationer tack vare sina datatyper, vilket kan påskynda fallscenarier genom att minska nätverkets I/O-antal och datastorlekar. Dessa dataoperationer är lika tunga som en get or set.
Vid Imaginärt moln Vi har använt båda i Många olika kunders projekt. I en som jag var involverad i, vi var tvungna att välja mellan de två alternativen. Först gick vi med Memcached baserat på dess enkelhet, användarvänlighet, enkel installation och vi behövde helt enkelt en cache så uthållighet var inte ett krav. Även om, efter några tester, vi bestämde oss för att byta till Redis på grund av fördelarna med att ha datatyper.
I detta projekt var datatypsoperationerna en fördel för den typ av data som skulle lagras. Redis tillhandahåller också ett kommando för att söka efter nycklar som matchar ett mönster tillsammans med många andra användbara kommandon för att hantera nycklar. Detta var något riktigt användbart för oss och en viktig punkt när vi beslutade att migrera till Redis.
När det gäller migreringen var det väldigt enkelt att utföra eftersom Redis stöder de flesta kommandon som Memcached gör. Om vi hade inverterat rutten och beslutat att migrera från Redis till Memcached hade det varit mycket svårare eftersom Memcached inte har några datatyper. Alla Redis-datatypskommando skulle ha översatts till många kommandon, tillsammans med viss databehandling mellan dem för att uppnå samma resultat.
När det gäller att fatta ett beslut kan vi inte riktigt säga att det ena är bättre än det andra, eftersom allt beror på projektkraven. Baserat på vår erfarenhet är det dock viktigt att överväga dess fördelar och nackdelar redan från början för att undvika förändringar och migreringar under projektet.


Webbutvecklare på Imaginärt moln, som är entusiastisk över Node.js och allt relaterat till back-end-utveckling.

VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta: