Redis vs. Memcached: Das Duell der In-Memory-Caches
Wer eine performante Web-Applikation betreibt, kommt früher oder später an einem In-Memory-Cache nicht vorbei. Die zwei beliebtesten Vertreter sind Redis und Memcached – beide halten Daten im Arbeitsspeicher, unterscheiden sich aber fundamental in Funktionsumfang, Architektur und Einsatzszenarien.
Was ist Memcached?
Memcached ist der ältere der beiden und seit 2003 im Einsatz. Das Design-Prinzip ist simpel: Ein verteilter, schlüsselwertbasierter Cache, der ausschließlich Strings speichert. Mehr nicht.
Stärken von Memcached:
- Extreme Einfachheit: Keine Konfigurationsfallen, kein Overhead
- Horizontale Skalierbarkeit: Mehrere Nodes lassen sich problemlos zusammenfassen
- Multi-Threading: Nutzt mehrere CPU-Kerne effizient aus
- Niedriger Speicher-Overhead pro gespeichertem Wert
Schwächen:
- Kein Persistieren von Daten (Reboot = Datenverlust)
- Nur String-Werte, keine komplexen Datenstrukturen
- Kein Pub/Sub, keine Queues, kein Scripting
- Kein eingebautes Clustering mit automatischem Failover
Memcached eignet sich perfekt für einfaches Session-Caching oder das Zwischenspeichern von Datenbankabfragen, bei denen komplexe Funktionen nicht benötigt werden.
Was ist Redis?
Redis (Remote Dictionary Server) ist seit 2009 im Einsatz und hat sich zur Schweizer Taschenmesser-Lösung unter den Caches entwickelt. Neben einfachem Key-Value-Caching unterstützt Redis:
- Listen, Sets, Sorted Sets, Hashes – komplexe Datenstrukturen
- Persistenz – Snapshots (RDB) und Append-Only-File (AOF)
- Pub/Sub-Messaging – für Echtzeit-Events
- Lua-Scripting – atomare, serverseitige Operationen
- Streams – Kafka-ähnliche Message-Queues
- Clustering und Sentinel – High Availability out of the box
- Transactions – MULTI/EXEC-Blöcke
Redis ist damit weit mehr als ein Cache: Es kann Session-Store, Message-Broker, Rate-Limiter, Leaderboard oder Task-Queue sein.
Direkte Gegenüberstellung
| Merkmal | Redis | Memcached |
|---|---|---|
| Datenstrukturen | Listen, Sets, Hashes, Streams, … | Nur Strings |
| Persistenz | Ja (RDB + AOF) | Nein |
| Clustering | Ja (Redis Cluster + Sentinel) | Manuell |
| Pub/Sub | Ja | Nein |
| Scripting | Lua | Nein |
| Multi-Threading | Single-threaded (I/O-Loop) | Multi-threaded |
| Speicher-Overhead | Etwas höher | Minimal |
| Komplexität | Höher | Sehr gering |
Wann Memcached, wann Redis?
Memcached wählen, wenn:
- Nur simples Key-Value-Caching benötigt wird
- Maximale Performance bei minimalem Overhead Priorität hat
- Einfachheit der Infrastruktur entscheidend ist
- Horizontale Skalierung ohne Clustering-Overhead gefragt ist
Redis wählen, wenn:
- Komplexe Datenstrukturen benötigt werden (Sorted Sets für Leaderboards, Listen für Queues)
- Datenpersistenz wichtig ist (Cache-Warming nach Restart)
- Pub/Sub oder Streams für Events genutzt werden sollen
- Ein einzelnes Tool mehrere Rollen übernehmen soll (Cache + Queue + Session Store)
Meine Empfehlung
In den meisten modernen Projekten empfehle ich Redis. Die Flexibilität, Persistenz und der Funktionsumfang überwiegen den minimal höheren Overhead. Wer Redis einsetzt, bekommt nicht nur einen Cache, sondern ein universelles Daten-Backend für viele Alltagsprobleme.
Memcached bleibt die richtige Wahl in Szenarien mit extremem Caching-Volumen, wo Threading-Performance entscheidend ist und man bewusst auf Komplexität verzichten möchte.
Fazit: Redis ist für Neuprojekte heute der klare Standard. Memcached ist nicht veraltet – aber der Anwendungsfall, wo es Redis schlägt, ist zunehmend selten.