Redis ist der Spezialist für schnelle Operationen – Caching, Session-Speicher, Message Queue, Rate Limiting. Alles im RAM, mikrosekunden-schnell, mit optionalem Persistenz-Modus. Der meistgenutzte Cache in modernen Web-Stacks.
CachePub/SubQueuesTTLKeyspace
Redis-Grundkonzepte: Datenstrukturen und TTL
Redis ist kein einfacher Key-Value-Store – es kennt mehrere Datenstrukturen:
Strings: Einfachster Typ – Caching von API-Responses, Session-Tokens, Zähler. SET key value EX 3600 mit 1h Ablaufzeit.
Hashes: Objekte mit mehreren Feldern – effizienter als JSON-String wenn einzelne Felder oft gelesen/geschrieben werden
Lists: Geordnete Listen – als einfache Queue: LPUSH zum Hinzufügen, RPOP zum Verarbeiten
Sorted Sets: Sets mit Score – Leaderboards, Rate-Limiting mit Zeitfenstern, Rangfolgen
Pub/Sub: Nachrichten publizieren und auf Channels abonnieren – leichtgewichtige Alternative zu MQTT für interne Service-Kommunikation
# Redis mit Python (redis-py)import redis
r = redis.Redis(host='localhost', decode_responses=True)
# Cache mit TTL
r.setex('api:weather:berlin', 3600, json_data)
cached = r.get('api:weather:berlin')
# Atomic Counter
r.incr('requests:total')
Redis als Cache für KI-Anfragen und API-Responses
Teurer API-Calls oder langsame LLM-Anfragen cachen spart Geld und Zeit:
Semantic Caching: Gleiche oder ähnliche Fragen an ein LLM nicht zweimal stellen – Response cachen und bei ähnlicher Frage wiederverwenden. Reduziert Ollama-Last erheblich.
API Rate Limiting: Anfragen pro API-Key zählen und begrenzen – Sorted Sets mit Sliding-Window-Pattern sind die eleganteste Lösung
Job Queues:n8n nutzt Redis intern als Queue-Backend (Queue Mode) – ermöglicht mehrere Worker-Instanzen
Session-Speicher: Schneller als Datenbank für kurzlebige Tokens und Auth-States
Redis betreiben: Persistenz, Cluster und Monitoring
Redis im RAM ist schnell – aber was passiert beim Neustart?
RDB Snapshots: Periodische Dumps auf Disk – schnell beim Neustart, aber letzte Änderungen seit dem letzten Snapshot verloren
AOF (Append Only File): Jeder Befehl wird geloggt – vollständige Wiederherstellbarkeit, etwas mehr I/O
Für Caching: Persistenz oft nicht nötig – Cache wird nach Neustart einfach neu aufgebaut. Spart I/O und Complexity.
Monitoring:redis-cli INFO zeigt Memory, Hit-Rate, Connected Clients. redis_exporter für Prometheus/Grafana.
Als Docker Container in Sekunden deployt: image: redis:7-alpine mit Volume für Persistenz wenn gewünscht.
Häufige Fragen zu Redis
Redis fast immer – mehr Datenstrukturen, Pub/Sub, Persistenz, aktive Weiterentwicklung. Memcached ist theoretisch etwas schneller für reines String-Caching bei sehr vielen Verbindungen – ein Vorteil der in der Praxis selten relevant ist.
Das hängt von den Daten ab. Mit `maxmemory 512mb` und einer Eviction Policy (`maxmemory-policy allkeys-lru`) begrenzen und alte Keys automatisch entfernen lassen wenn der Limit erreicht wird. Redis überwacht mit `redis-cli INFO memory` – tatsächlichen Verbrauch prüfen.
Nein – Redis sollte immer nur intern erreichbar sein. Kein Port-Mapping nach außen in compose.yml. Passwort mit requirepass setzen (auch intern – falls ein Container kompromittiert wird). Redis hatte historisch keine Auth – inzwischen verbessert, aber Isolation bleibt wichtig.
Für spezifische Use Cases ja – Leaderboards, Rate Limiting, Real-time Features. Als allgemeine Primärdatenbank: lieber PostgreSQL. Redis ergänzt PostgreSQL – es ersetzt es nicht. Die Kombination ist der Standard-Stack für performante Web-Applikationen.