Redis im Vergleich zu Memcached: Die richtige Engine auswählen

Amazon ElastiCache ist ein vollständig verwalteter In-Memory-Caching-Service, mit dem sich beliebte Open-Source-In-Memory-Datenspeicher ganz einfach in der Cloud bereitstellen, verwalten und skalieren lassen. Er unterstützt zwei Engines: Redis und Memcached. Indem häufig angeforderte Daten aus dem Arbeitsspeicher statt aus einer Datenbank bereitgestellt werden, kann ElastiCache die Datenbanklast um Größenordnungen reduzieren und die Antwortlatenz von Millisekunden auf Mikrosekunden senken. Die Wahl zwischen Redis und Memcached ist eine häufige Prüfungsfrage im SAA-C03-Examen.

Memcached ist ein verteilter In-Memory-Key-Value-Store, der auf Einfachheit und horizontale Skalierbarkeit ausgerichtet ist. Die wichtigsten Eigenschaften: Multithreading (kann alle CPU-Kerne eines einzelnen Knotens nutzen), einfache Key-Value-Speicherung (nur Zeichenfolgen, keine komplexen Datenstrukturen), keine Persistenz (Daten gehen beim Neustart eines Knotens verloren), keine Replikation (keine Standby-Knoten oder Replikate) und horizontales Sharding über konsistentes Hashing auf Clientseite. Memcached ist die richtige Wahl, wenn Sie einen einfachen Cache in großem Maßstab benötigen und weder Persistenz oder komplexe Datentypen noch hohe Verfügbarkeit erforderlich sind.

Redis (Remote Dictionary Server) ist ein Single-Threaded-In-Memory-Datenspeicher für Datenstrukturen mit umfangreichen Funktionen, der Zeichenfolgen, Hashes, Listen, Mengen, sortierte Mengen, Bitmaps, HyperLogLogs, Streams und geografische Indizes unterstützt. Die wichtigsten Vorteile gegenüber Memcached: optionale Persistenz (AOF- und RDB-Snapshots), Replikation (Lesereplikate und automatisches Failover), Pub/Sub-Messaging, Lua-Scripting, Transaktionen (MULTI/EXEC) und der Cluster-Modus für horizontales Sharding. Redis ist für die meisten Caching-Szenarien aus der Praxis die richtige Wahl.

Redis unterstützt zwei Persistenzmechanismen: RDB (Redis Database) – regelmäßige Point-in-Time-Snapshots, die in konfigurierbaren Intervallen auf der Festplatte gespeichert werden (schnelle Neustarts, aber möglicher Datenverlust zwischen den Snapshots). AOF (Append-Only File) – protokolliert jeden Schreibvorgang; beim Neustart gibt Redis das Protokoll wieder, um den Zustand zu rekonstruieren (höhere Dauerhaftigkeit auf Kosten größerer Dateien und langsamerer Neustarts). In ElastiCache können Sie AOF aktivieren, um Daten über Neustarts von Knoten hinweg zu persistieren. Dies ist besonders wichtig, wenn ElastiCache nicht nur als Cache, sondern beispielsweise als primärer Datenspeicher für Sitzungsdaten verwendet wird.

Redis unterstützt Replikationsgruppen mit einem primären Knoten, der alle Schreibvorgänge verarbeitet, und bis zu fünf Lesereplikaten, die Lesevorgänge verarbeiten. Wenn Multi-AZ und automatisches Failover aktiviert sind, stuft ElastiCache bei einem Ausfall des primären Knotens automatisch ein Lesereplikat zum primären Knoten hoch – in der Regel ist das Failover in weniger als 60 Sekunden abgeschlossen. Dadurch erhalten Redis-basierte Anwendungen eine hohe Verfügbarkeit, die Memcached nicht bieten kann (Memcached unterstützt keine Replikation). Für Produktionsanwendungen, die hochverfügbares Caching benötigen, sollten Sie immer Redis mit automatischem Failover verwenden.

Sortierte Mengen gehören zu den leistungsfähigsten Datenstrukturen von Redis. Jedes Mitglied verfügt über einen zugehörigen Gleitkommawert als Score, und die Mitglieder werden stets sortiert gehalten. Dadurch eignen sich sortierte Mengen ideal für Ranglisten (Sortierung nach Score), Prioritätswarteschlangen (Jobs mit der höchsten Priorität zuerst verarbeiten) und Rate Limiting (gleitendes Zeitfenster mit Zeitstempeln als Scores). Die Operationen ZADD, ZRANGE, ZREVRANGE, ZRANK und ZRANGEBYSCORE haben alle die Komplexität O(log n) und sind daher selbst bei Millionen von Einträgen äußerst effizient.

Mit Pub/Sub in Redis können Publisher Nachrichten an Channels senden, ohne zu wissen, wer diese abonniert hat. Subscriber erhalten in Echtzeit alle Nachrichten, die an von ihnen abonnierte Channels gesendet werden. Pub/Sub-Nachrichten werden nicht persistiert – ist ein Subscriber offline, verpasst er die Nachricht. Für persistentes Messaging mit garantierter Zustellung verwenden Sie Redis Streams (eine robustere Datenstruktur, die in Redis 5 hinzugefügt wurde) oder einen speziell dafür entwickelten Messaging-Service wie SQS oder SNS. Für das SAA-C03-Examen ist Redis Pub/Sub eine Option für leichte Echtzeitbenachrichtigungen zwischen Services.

Verwenden Sie für das SAA-C03-Examen den folgenden Entscheidungsrahmen: Wählen Sie Memcached, wenn Sie Folgendes benötigen: einen einfachen Cache ohne Anforderungen an hohe Verfügbarkeit, Multithreading-Performance und horizontale Skalierung durch das Hinzufügen von Knoten (reiner Cache). Wählen Sie Redis, wenn Sie Folgendes benötigen: Persistenz (Sitzungsspeicher), Replikation und Failover (hohe Verfügbarkeit), komplexe Datentypen (sortierte Mengen für Ranglisten, Mengen, Listen), Pub/Sub, Lua-Transaktionen oder den Cluster-Modus für horizontale Skalierung über mehrere Shards. Wenn in der Prüfungsfrage eine Funktion genannt wird, die über einfaches Key-Value-Caching hinausgeht, ist Redis fast immer die richtige Antwort.

ElastiCache bietet mehrere Knotentypfamilien: r7g (Graviton 3, speicheroptimiert – bestes Preis-Leistungs-Verhältnis, für die meisten Caching-Szenarien empfohlen), m7g (ausgewogenes Verhältnis von Rechenleistung und Arbeitsspeicher) und t4g (burstable, kostengünstig für Entwicklung und Tests). Die Knotengrößen reichen von cache.t4g.micro (500 MB) bis cache.r7g.16xlarge (425 GB). Wählen Sie für die Produktion eine Knotengröße, die Ihren gesamten Datensatz im Arbeitsspeicher mit einer Reserve von 20–25 % halten kann. Wenn der Arbeitsspeicher knapp wird, kommt es zu Evictions (Memcached) oder OOM-Fehlern (Redis).

ElastiCache wird innerhalb Ihrer VPC bereitgestellt, wobei Security Groups den Zugriff steuern – standardmäßig besteht kein Zugriff über das öffentliche Internet. Aktivieren Sie für Redis AUTH-Tokens (ein Kennwort, das Clients angeben müssen) und die Verschlüsselung während der Übertragung (TLS) für Verbindungen sowie die Verschlüsselung im Ruhezustand mit KMS. Für Memcached ist nur TLS für die Verschlüsselung während der Übertragung verfügbar (keine Verschlüsselung im Ruhezustand und kein AUTH). Bei der Migration von unverschlüsseltem zu verschlüsseltem Redis gibt es keine Migration an Ort und Stelle – Sie müssen einen neuen verschlüsselten Cluster erstellen und ihn vorab mit Daten füllen.

Wenn ein Redis- oder Memcached-Cache voll ist, bestimmt die Eviction-Richtlinie, welche Schlüssel entfernt werden, um Platz zu schaffen. Gängige Eviction-Richtlinien für Redis: noeviction (gibt einen OOM-Fehler zurück – geeignet, wenn der Cache als primärer Datenspeicher dient), allkeys-lru (entfernt den am längsten nicht verwendeten Schlüssel aus allen Schlüsseln – geeignet für allgemeine Caches), volatile-lru (LRU unter den Schlüsseln mit gesetztem TTL – erhält Schlüssel ohne Ablaufzeit), allkeys-random (zufällige Eviction) und allkeys-lfu (am seltensten verwendet). Für typische Caching-Szenarien werden allkeys-lru oder allkeys-lfu empfohlen.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: Memcached ist einfach, multithreadfähig und bietet keine hohe Verfügbarkeit – ideal für die reine horizontale Skalierung einfacher Caches, Redis unterstützt komplexe Datenstrukturen, Persistenz, Pub/Sub und Multi-AZ-Failover – ideal für die meisten Produktionsszenarien mit Caching, und sortierte Mengen machen Redis zur naheliegenden Wahl für Ranglisten und Prioritätswarteschlangen. Als Nächstes beschäftigen wir uns mit Redis-Replikationsgruppen und dem Cluster-Modus für horizontales Sharding.