Sammanfattning (TL;DR)
Uppdaterad 3 juni 2017
Redis är kraftfullare, mer populär och stöds bättre än memcachad. Memcached kan bara göra en liten bråkdel av de saker som Redis kan göra. Redis är bättre även där deras funktioner överlappar varandra.
För allt nytt, använd Redis.
Memcached vs Redis:Direct Comparison
Båda verktygen är kraftfulla, snabba datalager i minnet som är användbara som cache. Båda kan hjälpa till att påskynda din ansökan genom att cachelagra databasresultat, HTML-fragment eller något annat som kan vara dyrt att generera.
Poäng att tänka på
När de används för samma sak, så jämför de med den ursprungliga frågans "Poäng att överväga":
- Läs-/skrivhastighet :Båda är extremt snabba. Benchmarks varierar beroende på arbetsbelastning, versioner och många andra faktorer men visar generellt att redis är lika snabb eller nästan lika snabb som memcached. Jag rekommenderar redis, men inte för att memcached är långsam. Det är det inte.
- Minnesanvändning :Redis är bättre.
- memcached:Du anger cachestorleken och när du infogar objekt växer demonen snabbt till lite mer än denna storlek. Det finns aldrig riktigt ett sätt att återta något av det utrymmet, förutom att starta om memcached. Alla dina nycklar kan vara utgångna, du kan spola databasen och den skulle fortfarande använda hela RAM-minnet du konfigurerade den med.
- redis:Att ställa in en maxstorlek är upp till dig. Redis kommer aldrig att använda mer än det måste och kommer att ge dig tillbaka minne som det inte längre använder.
- Jag lagrade 100 000 ~2KB-strängar (~200MB) slumpmässiga meningar i båda. Memcached RAM-användning växte till ~225MB. Redis RAM-användning växte till ~228MB. Efter att ha tömt båda, sjönk redis till ~29MB och memcached stannade på ~225MB. De är lika effektiva i hur de lagrar data, men bara en kan återta den.
- Disk I/O-dumpning :En klar vinst för redis eftersom den gör detta som standard och har mycket konfigurerbar uthållighet. Memcached har inga mekanismer för dumpning till disk utan verktyg från tredje part.
- Skalning :Båda ger dig massor av utrymme innan du behöver mer än en enda instans som cache. Redis innehåller verktyg som hjälper dig att gå utöver det medan memcached inte gör det.
memcachad
Memcached är en enkel flyktig cacheserver. Det låter dig lagra nyckel/värdepar där värdet är begränsat till att vara en sträng på upp till 1 MB.
Den är bra på det här, men det är allt det gör. Du kan komma åt dessa värden med hjälp av deras nyckel med extremt hög hastighet, vilket ofta mättar tillgängligt nätverk eller till och med minnesbandbredd.
När du startar om memcached är din data borta. Det här är bra för en cache. Du bör inte lagra något viktigt där.
Om du behöver hög prestanda eller hög tillgänglighet finns verktyg, produkter och tjänster från tredje part tillgängliga.
redis
Redis kan göra samma jobb som memcached kan, och kan göra dem bättre.
Redis kan också fungera som en cache. Den kan också lagra nyckel/värdepar. I redis kan de till och med vara upp till 512MB.
Du kan stänga av persistens och det kommer glatt att förlora din data vid omstart också. Om du vill att din cache ska överleva omstarter den låter dig göra det också. Det är faktiskt standarden.
Det är också supersnabbt, ofta begränsat av nätverks- eller minnesbandbredd.
Om en instans av redis/memcached inte räcker till för din arbetsbelastning är redis det självklara valet. Redis inkluderar klusterstöd och kommer med verktyg för hög tillgänglighet (redis-sentinel) direkt "i lådan". Under de senaste åren har redis också framstått som den tydliga ledaren inom tredjepartsverktyg. Företag som Redis Labs, Amazon och andra erbjuder många användbara redis-verktyg och tjänster. Ekosystemet runt redis är mycket större. Antalet storskaliga distributioner är nu troligen större än för memcached.
Redis Superset
Redis är mer än en cache. Det är en datastrukturserver i minnet. Nedan hittar du en snabb översikt över saker som Redis kan göra utöver att vara en enkel nyckel-/värdecache som memcached. De flesta av redis funktioner är saker som memcached inte kan göra.
Dokumentation
Redis är bättre dokumenterat än memcachad. Även om detta kan vara subjektivt, verkar det vara mer och mer sant hela tiden.
redis.io är en fantastisk lättnavigerad resurs. Det låter dig prova redis i webbläsaren och ger dig till och med interaktiva exempel med varje kommando i dokumenten.
Det finns nu 2 gånger så många stackoverflow-resultat för redis som memcached. 2 gånger så många Google-resultat. Mer lättillgängliga exempel på fler språk. Mer aktiv utveckling. Mer aktiv kundutveckling. Dessa mätningar betyder kanske inte så mycket individuellt, men i kombination målar de en tydlig bild av att stöd och dokumentation för redis är större och mycket mer uppdaterad.
Uthållighet
Som standard behåller redis dina data till disk med en mekanism som kallas snapshotting. Om du har tillräckligt med RAM tillgängligt kan den skriva all din data till disken med nästan ingen prestandaförsämring. Det är nästan gratis!
I ögonblicksbildsläge finns det en chans att en plötslig krasch kan resultera i en liten mängd förlorad data. Om du absolut behöver se till att ingen data någonsin går förlorad, oroa dig inte, redis har din rygg där också med AOF-läget (Append Only File). I det här beständighetsläget kan data synkroniseras till disk när de skrivs. Detta kan minska den maximala skrivkapaciteten till hur snabbt din hårddisk kan skriva, men bör fortfarande vara ganska snabb.
Det finns många konfigurationsalternativ för att finjustera uthållighet om du behöver, men standardinställningarna är mycket förnuftiga. Dessa alternativ gör det enkelt att ställa in redis som en säker, redundant plats att lagra data. Det är en riktig databas.
Många datatyper
Memcached är begränsat till strängar, men Redis är en datastrukturserver som kan tjäna många olika datatyper. Den tillhandahåller också de kommandon du behöver för att få ut det mesta av dessa datatyper.
Strängar (kommandon)
Enkel text eller binära värden som kan vara upp till 512 MB stora. Detta är den enda datatypen redis och memcached share, även om memcachade strängar är begränsade till 1 MB.
Redis ger dig fler verktyg för att utnyttja denna datatyp genom att erbjuda kommandon för bitvisa operationer, bitnivåmanipulation, flyttalsökning/dekrementeringsstöd, avståndsfrågor och flernyckeloperationer. Memcached stöder inget av det.
Strängar är användbara för alla möjliga användningsfall, vilket är anledningen till att memcached är ganska användbart med enbart den här datatypen.
Hashar (kommandon)
Hashes är ungefär som ett nyckelvärdeslager i ett nyckelvärdeslager. De mappar mellan strängfält och strängvärden. Fält->värdekartor som använder en hash är något mer utrymmeseffektiva än nyckel->värdekartor med vanliga strängar.
Hashes är användbara som ett namnutrymme, eller när du logiskt vill gruppera många nycklar. Med en hash kan du ta tag i alla medlemmar effektivt, förfalla alla medlemmar tillsammans, ta bort alla medlemmar tillsammans, etc. Perfekt för alla användningsfall där du har flera nyckel-/värdepar som måste grupperas.
Ett exempel på användning av en hash är för att lagra användarprofiler mellan applikationer. En redis-hash som lagras med användar-ID som nyckel gör att du kan lagra så många bitar av data om en användare som behövs samtidigt som de lagras under en enda nyckel. Fördelen med att använda en hash istället för att serialisera profilen till en sträng är att du kan låta olika applikationer läsa/skriva olika fält i användarprofilen utan att behöva oroa dig för att en app åsidosätter ändringar gjorda av andra (vilket kan hända om du serialiserar inaktuella data).
Listor (kommandon)
Redis-listor är ordnade samlingar av strängar. De är optimerade för att infoga, läsa eller ta bort värden från toppen eller botten (aka:vänster eller höger) i listan.
Redis tillhandahåller många kommandon för att utnyttja listor, inklusive kommandon för att push/pop-objekt, push/pop mellan listor, trunkera listor, utföra intervallfrågor, etc.
Listor gör stora hållbara, atomära, köer. Dessa fungerar utmärkt för jobbköer, loggar, buffertar och många andra användningsfall.
Inställningar (kommandon)
Set är oordnade samlingar av unika värden. De är optimerade för att du snabbt ska kunna kontrollera om ett värde finns i uppsättningen, snabbt lägga till/ta bort värden och för att mäta överlappning med andra uppsättningar.
Dessa är bra för saker som åtkomstkontrollistor, unika besöksspårare och många andra saker. De flesta programmeringsspråk har något liknande (vanligtvis kallat set). Det här är så, bara distribuerat.
Redis tillhandahåller flera kommandon för att hantera uppsättningar. Uppenbara sådana som att lägga till, ta bort och kontrollera setet finns. Så är mindre uppenbara kommandon som att poppa/läsa ett slumpmässigt objekt och kommandon för att utföra fackföreningar och korsningar med andra uppsättningar.
Sorterade uppsättningar (kommandon)
Sorterade uppsättningar är också samlingar av unika värden. Dessa är, som namnet antyder, beställda. De är ordnade efter ett partitur, sedan lexikografiskt.
Denna datatyp är optimerad för snabba sökningar efter poäng. Det går extremt snabbt att få de högsta, lägsta eller något intervall av värden däremellan.
Om du lägger till användare till en sorterad uppsättning tillsammans med deras höga poäng, har du själv en perfekt topplista. När nya höga poäng kommer in, lägg bara till dem i setet igen med deras höga poäng och det kommer att omordna din topplista. Också bra för att hålla reda på senast användare besökte och vem som är aktiv i din applikation.
Att lagra värden med samma poäng gör att de ordnas lexikografiskt (tänk alfabetiskt). Detta kan vara användbart för saker som funktioner för automatisk komplettering.
Många av de sorterade setkommandona liknar kommandon för set, ibland med en extra poängparameter. Dessutom ingår kommandon för att hantera poäng och fråga efter poäng.
Geo
Redis har flera kommandon för att lagra, hämta och mäta geografisk data. Detta inkluderar radiefrågor och mätning av avstånd mellan punkter.
Tekniskt sett lagras geografisk data i redis i sorterade uppsättningar, så detta är inte en riktigt separat datatyp. Det är mer en förlängning ovanpå sorterade uppsättningar.
Bitmapp och HyperLogLog
Precis som geo är dessa inte helt separata datatyper. Det här är kommandon som låter dig behandla strängdata som om det antingen är en bitmapp eller en hyperlogg.
Bitmappar är vad de bitnivåoperatorer jag refererade till under Strings är för. Denna datatyp var den grundläggande byggstenen för reddits senaste konstprojekt:r/Place.
HyperLogLog låter dig använda en konstant extremt liten mängd utrymme för att räkna nästan obegränsade unika värden med chockerande noggrannhet. Med endast ~16KB kan du effektivt räkna antalet unika besökare på din webbplats, även om antalet är i miljoner.
Transaktioner och atomicitet
Kommandon i redis är atomiska, vilket innebär att du kan vara säker på att så snart du skriver ett värde till redis är det värdet synligt för alla klienter som är anslutna till redis. Det finns ingen väntan på att det värdet ska spridas. Tekniskt är memcached också atomärt, men med redis som lägger till all denna funktionalitet utöver memcached är det värt att notera och något imponerande att alla dessa ytterligare datatyper och funktioner också är atomära.
Även om det inte är detsamma som transaktioner i relationsdatabaser, har redis också transaktioner som använder "optimistisk låsning" (WATCH/MULTI/EXEC).
Rörledning
Redis tillhandahåller en funktion som kallas "pipelining". Om du har många redis-kommandon som du vill köra kan du använda pipelining för att skicka dem till redis all-at-once istället för en i taget.
Normalt när du kör ett kommando för att antingen redis eller memcached, är varje kommando en separat begäran/svarscykel. Med pipelining kan redis buffra flera kommandon och köra dem alla samtidigt och svara med alla svar på alla dina kommandon i ett enda svar.
Detta kan tillåta dig att uppnå ännu större genomströmning vid massimport eller andra åtgärder som involverar många kommandon.
Pub/Sub
Redis har kommandon dedikerade till pub/sub-funktionalitet, vilket gör att redis kan fungera som en höghastighetsmeddelandesändare. Detta tillåter en enskild klient att publicera meddelanden till många andra klienter som är anslutna till en kanal.
Redis gör pub/sub liksom nästan alla verktyg. Dedikerade meddelandeförmedlare som RabbitMQ kan ha fördelar inom vissa områden, men det faktum att samma server också kan ge dig ihållande hållbara köer och andra datastrukturer som dina pub-/sub-arbetsbelastningar sannolikt behöver, kommer Redis ofta visa sig vara det bästa och enklaste verktyget för jobbet.
Lua Scripting
Du kan typ tänka på lua-skript som redis egen SQL eller lagrade procedurer. Det är både mer och mindre än så, men analogin fungerar för det mesta.
Kanske har du komplexa beräkningar som du vill att redis ska utföra. Kanske har du inte råd att få dina transaktioner att rulla tillbaka och behöver garantier för att varje steg i en komplex process kommer att ske atomärt. Dessa problem och många fler kan lösas med lua scripting.
Hela skriptet körs atomärt, så om du kan passa in din logik i ett lua-skript kan du ofta undvika att bråka med optimistiska låstransaktioner.
Skalning
Som nämnts ovan inkluderar redis inbyggt stöd för klustring och levereras med sitt eget verktyg för hög tillgänglighet som heter redis-sentinel .
Slutsats
Utan att tveka skulle jag rekommendera redis over memcached för alla nya projekt, eller befintliga projekt som inte redan använder memcached.
Ovanstående kan låta som att jag inte gillar memcached. Tvärtom:det är ett kraftfullt, enkelt, stabilt, moget och härdat verktyg. Det finns till och med vissa användningsfall där det är lite snabbare än redis. Jag älskar memcached. Jag tycker helt enkelt inte att det är så vettigt för framtida utveckling.
Redis gör allt memcached gör, ofta bättre. Eventuella prestandafördelar för memcached är mindre och arbetsbelastningsspecifika. Det finns också arbetsbelastningar för vilka redis kommer att vara snabbare, och många fler arbetsbelastningar som redis kan göra som memcached helt enkelt inte kan. De små prestandaskillnaderna verkar små inför den gigantiska klyftan i funktionalitet och det faktum att båda verktygen är så snabba och effektiva att de mycket väl kan vara den sista biten av din infrastruktur du någonsin behöver oroa dig för att skala.
Det finns bara ett scenario där memcached är mer vettigt:där memcached redan används som en cache. Om du redan cachar med memcached, fortsätt att använda det, om det uppfyller dina behov. Det är sannolikt inte värt ansträngningen att flytta till redis och om du ska använda redis bara för att cachelagra kanske det inte ger tillräckligt med fördel för att vara värt din tid. Om memcached inte uppfyller dina behov, bör du förmodligen flytta till redis. Detta gäller oavsett om du behöver skala utöver memcached eller om du behöver ytterligare funktionalitet.