Redis im Betrieb: Datentypen, Haltbarkeit und Speichergrenzen

Redis ist ein Schlüssel-Wert-Speicher, der alles im Arbeitsspeicher hält. Daraus folgt sein wichtigstes Merkmal: Zugriffe dauern Mikrosekunden statt Millisekunden. Der Preis ist der begrenzte Speicher und die Frage, was nach einem Neustart noch vorhanden ist.

\n

Wofür Redis geeignet ist

\n
    \n
  • Zwischenspeicher: Ergebnis teurer Abfragen für kurze Zeit vorhalten. Der häufigste Anwendungsfall.
    • \n
  • Sitzungen: Weil alle Anwendungsinstanzen denselben Speicher nutzen, braucht kein Lastverteiler Sitzungstreue. Dafür sind Zustandsspeicher mit kurzer Lebensdauer genau richtig.
    • \n
  • Ratenbegrenzung: Zähler mit Ablaufzeit – atomar und schnell.
    • \n
  • Warteschlangen: Listen und Streams für einfache Auftragsverarbeitung.
    • \n
  • Echtzeit-Ranglisten: Sortierte Mengen (Sorted Sets) liefern Rangfolgen in konstanter Zeit.
    • \n
  • Verteilte Sperren: Ein Schlüssel mit Ablaufzeit als einfache Sperre – mit den weiter unten genannten Einschränkungen.
    • \n
\n

Nicht geeignet als Hauptdatenbank für alles, was nicht verloren gehen darf. Redis kann Daten dauerhaft speichern, aber die Entwurfsentscheidungen sind auf Geschwindigkeit ausgerichtet, nicht auf Haltbarkeit.

\n

Die Datentypen

\n
# Strings - einfachste Form, auch fuer Zahlen und Binaerdaten\nSET sitzung:4711 "{\\"user\\":\\"max\\"}" EX 3600     # mit Ablaufzeit\nGET sitzung:4711\nINCR aufrufe:heute                                # atomar erhoehen\nINCRBY aufrufe:heute 5\nTTL sitzung:4711                                  # Restlaufzeit in Sekunden\nEXPIRE aufrufe:heute 86400\n\n# Hash - ein Objekt mit Feldern\nHSET server:web01 ip 10.0.0.11 port 22 aktiv 1\nHGET server:web01 ip\nHGETALL server:web01\nHINCRBY server:web01 aufrufe 1\n\n# List - Warteschlange oder Stapel\nLPUSH auftraege "job1"          # links anfuegen\nRPUSH auftraege "job2"          # rechts anfuegen\nLPOP auftraege                  # links entnehmen (Warteschlange)\nBRPOP auftraege 30              # blockierend warten bis 30 s\nLRANGE auftraege 0 -1           # alle ansehen\nLLEN auftraege\n\n# Set - eindeutige Werte, Mengenoperationen\nSADD tags:artikel1 "linux" "netzwerk"\nSMEMBERS tags:artikel1\nSINTER tags:artikel1 tags:artikel2       # Schnittmenge\nSUNION tags:artikel1 tags:artikel2\nSCARD tags:artikel1\n\n# Sorted Set - Ranglisten mit Gewichtung\nZADD bestseller 42 "artikel1" 17 "artikel2"\nZRANGE bestseller 0 -1 WITHSCORES        # aufsteigend\nZREVRANGE bestseller 0 9 WITHSCORES      # absteigend, Top 10\nZINCRBY bestseller 1 "artikel1"\nZRANK bestseller "artikel2"              # Rang ermitteln\n\n# Streams - Ereignisprotokoll mit Gruppen\nXADD ereignisse * typ login host web01\nXLEN ereignisse\nXREAD COUNT 10 STREAMS ereignisse 0\nXGROUP CREATE ereignisse arbeiter $\nXREADGROUP GROUP arbeiter w1 COUNT 5 STREAMS ereignisse >\n\n# Binaer und Bitmap\nSETBIT besuche:2026-09-26 4711 1\nBITCOUNT besuche:2026-09-26\nPFADD unique:heute 192.0.2.1 192.0.2.2     # HyperLogLog: Naeherung\nPFCOUNT unique:heute
\n

Haltbarkeit: RDB und AOF

\n

Redis speichert auf zwei Wegen dauerhaft – und beide haben unterschiedliche Eigenschaften:

\n
    \n
  • RDB (Momentaufnahme): In festen Abständen wird der gesamte Speicher in eine Datei geschrieben. Kompakt, schnell zu laden, gut für Sicherungen. Dafür geht der Inhalt zwischen den Aufnahmen verloren.
    • \n
  • AOF (Protokoll): Jede schreibende Operation wird protokolliert. Bei appendfsync always ist fast nichts verloren, aber es kostet Leistung. everysec ist der übliche Kompromiss.
    • \n
\n
# /etc/redis/redis.conf\nsave 900 1          # RDB: nach 900 s, wenn mind. 1 Aenderung\nsave 300 10\nsave 60 10000\nappendonly yes              # AOF aktivieren\nappendfsync everysec        # always | everysec | no\nauto-aof-rewrite-percentage 100\nauto-aof-rewrite-min-size 64mb\n\n# Speicher begrenzen (PFLICHT im Betrieb!)\nmaxmemory 2gb\n# Was passiert bei vollem Speicher?\nmaxmemory-policy allkeys-lru       # aelteste ungenutzte Schluessel verdraengen\n#   noeviction       Fehler bei Schreibzugriffen (fuer echte Datenbanken)\n#   allkeys-lru      alles ist verdraengbar (reiner Zwischenspeicher)\n#   volatile-lru     nur Schluessel MIT Ablaufzeit verdraengen\n#   allkeys-lfu      nach Haeufigkeit der Nutzung\n#   volatile-ttl     die kuerzeste Restlaufzeit zuerst\n\n# Speichern und laden\nredis-cli BGSAVE\nredis-cli BGREWRITEAOF\nredis-cli LASTSAVE\nredis-cli INFO persistence
\n

Die wichtigste Einstellung ist maxmemory mit einer maxmemory-policy. Ohne Grenze kann Redis den gesamten Arbeitsspeicher füllen; das Betriebssystem beendet dann den Prozess (OOM-Killer) – ohne Vorwarnung und mit Verlust aller nicht gesicherten Daten.

\n

Betrieb und Diagnose

\n
# Zustand\nredis-cli INFO\nredis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|evicted'\nredis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'\nredis-cli DBSIZE\nredis-cli --bigkeys                  # groesste Schluessel finden\nredis-cli --scan --pattern 'sitzung:*' | head -20\nredis-cli MEMORY USAGE schluesselname\n\n# Trefferquote berechnen\n#   hits / (hits + misses)\n#   Unter 80 % -> Zwischenspeicherung ist schlecht abgestimmt\n#   und evicted_keys steigt -> Speicher zu klein\n\n# Laufzeitbefehle\nredis-cli SLOWLOG GET 10             # langsame Befehle\nredis-cli CLIENT LIST                # verbundene Clients\nredis-cli --latency                  # Laufzeit messen\nredis-cli DEBUG SLEEP 2              # NICHT in Produktion!\n\n# Schluessel mit Ablaufzeit durchsuchen\nredis-cli --scan --pattern 'sitzung:*' | head\nredis-cli TTL sitzung:4711\n\n# Auftragswarteschlange beobachten\nredis-cli LLEN auftraege\nredis-cli XINFO GROUPS ereignisse
\n

Verteilte Sperren – mit Vorsicht

\n

Die naheliegende Sperre ist ein Schlüssel mit Ablaufzeit. Das ist in einfachen Fällen brauchbar, hat aber eine bekannte Schwäche: Hält der Sperrinhaber länger als die Ablaufzeit, läuft die Sperre ab und ein zweiter Prozess nimmt sie. Der erste arbeitet dann unwissentlich parallel weiter.

\n
# Einfache Sperre - ausreichend, wenn ein Doppelauf nicht katastrophal ist\nSET sperre:export "worker-1" NX EX 60\n#   NX = nur setzen, wenn nicht vorhanden\n#   EX 60 = nach 60 Sekunden automatisch freigeben\n\n# Freigeben nur, wenn man selbst der Inhaber ist (atomar ueber Lua)\nEVAL "if redis.call('get', KEYS[1]) == ARGV[1] then\n        return redis.call('del', KEYS[1]) else return 0 end" 1 sperre:export worker-1\n\n# Fuer kritische Ablaeufe: Redlock mit mehreren unabhaengigen Redis-Instanzen\n# - und trotzdem braucht der geschuetzte Vorgang Idempotenz,\n#   damit ein doppelter Lauf keinen Schaden anrichtet.
\n

Faustregel: Eine Sperre ist eine Optimierung, kein Korrektheitsbeweis. Wer Korrektheit braucht, macht den Vorgang idempotent – dann ist ein Doppellauf unschädlich und die Frage der Sperre wird sekundär.

\n

Sicherheit

\n
    \n
  1. Niemals ohne Schutz ins Internet. Redis hat lange Zeit ohne Authentifizierung gelauscht und wurde massenhaft für Erpressung und Kryptomining missbraucht. Der Standardbind ist 127.0.0.1 – das ist richtig so.
    2. \n
  2. protected-mode yes lassen und nur bei Bedarf und mit Bedacht ändern.
    3. \n
  3. Authentifizierung ab Redis 6 mit Zugriffskonten (ACL): Nicht ein einziges Passwort für alles, sondern Benutzer mit Rechten nur auf bestimmte Schlüsselmuster und Befehle.
    4. \n
  4. Gefährliche Befehle umbenennen oder abschalten: FLUSHALL, FLUSHDB, CONFIG, KEYS, DEBUG. Ein einzelner Aufruf kann sonst alles löschen.
    5. \n
  5. TLS aktivieren für Verbindungen über Netze, die nicht vertrauenswürdig sind.
    6. \n
  6. Speicherung von Geheimnissen abwägen: Sitzungen enthalten oft Token. Wer Zugriff auf Redis hat, übernimmt damit Konten. Zugriff eng fassen und Speicher verschlüsseln.
    7. \n
\n
# /etc/redis/redis.conf - Sicherheit\nbind 127.0.0.1 ::1\nprotected-mode yes\nrequirepass einSehrLangesZufaelligesPasswort\nrename-command FLUSHALL ""\nrename-command FLUSHDB ""\nrename-command CONFIG "CONFIG_c9f1a7b2"\nrename-command KEYS ""\n\n# ACL (ab Redis 6)\n# ACL SETUSER app on >geheim ~cache:* +get +set +expire\n# ACL LIST\n# ACL WHOAMI
\n

Prüfliste

\n
    \n
  1. Ist maxmemory gesetzt – und passt die Richtlinie zum Verwendungszweck?
    2. \n
  2. Wie hoch ist die Trefferquote? Unter 80 % lohnt die Überprüfung der Zwischenspeicherung.
    3. \n
  3. Steigt evicted_keys? Dann ist der Speicher zu klein oder die Ablaufzeiten sind zu lang.
    4. \n
  4. Ist die Haltbarkeit so eingestellt, wie es die Anwendung braucht (AOF an oder aus)?
    5. \n
  5. Laufen Sicherungen – und wurde eine Wiederherstellung je geprüft?
    6. \n
  6. Ist der Zugriff beschränkt und authentifiziert?
    7. \n
  7. Werden große Schlüssel verwendet? Ein Hash mit einer Million Felder blockiert den Server bei jedem Zugriff. --bigkeys findet sie.
    8. \n
  8. Laufen Massenabfragen über KEYS? Das blockiert den Server – stattdessen SCAN verwenden.
    9. \n
\n

Verwandte Grundlagen: Redis, Cache, Message Queue, Monitoring.