Redis-Cache- und Queue-Workloads auf Dockup

**Redis-Cache- und Queue-**Workloads können denselben Managed-Redis-Service verwenden, haben aber unterschiedliche Anforderungen an die Korrektheit. Ein Cache lässt sich normalerweise nach einem Verlust neu aufbauen. Eine Queue kann dagegen Arbeit repräsentieren, die nicht unbemerkt verworfen oder doppelt verarbeitet werden darf.

Dockup stellt Redis als Managed Database bereit, unterstützt Größen- und Log-Operationen sowie Workflows für Backups und Node-Migrationen und kann die Datenbank über projektspezifisches privates Networking mit Application Services verbinden.

Wie stellt man Managed Redis bereit?

Erstelle Redis im ausgewählten Workspace:

dockup db create \
  --name app-redis \
  --type redis \
  --json

Überprüfe das Datenbankziel:

dockup db list --json

Speichere die zurückgegebenen Verbindungsdaten außerhalb der Versionsverwaltung und hinterlege sie beim konsumierenden Service als Secret:

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Beim Redeploy wird ein neuer Application Container mit der aktualisierten Umgebung erstellt. Ein Neustart des alten Containers übernimmt keinen neu gespeicherten gewünschten Wert.

Verwende separate Redis-Datenbanken oder Instanzen, wenn sich das Eviction-Verhalten des Caches und die kritische Aufbewahrung von Queue-Einträgen nicht denselben Speicher teilen sollen. Die Isolation erleichtert außerdem die Störungsanalyse und die Zugriffskontrolle.

Wann sollte Redis als Cache eingesetzt werden?

Ein Cache reduziert wiederholte Arbeit oder Latenz, indem er abgeleitete Daten speichert. Die Source of Truth bleibt an anderer Stelle, typischerweise in PostgreSQL, MySQL, MongoDB, einer externen API oder einer deterministischen Berechnung.

Ein solides Cache-Design definiert:

• Format und Namespace der Cache-Keys.
• Time to live.
• Maximal akzeptable Veralterung.
• Auslöser für die Invalidierung.
• Verhalten bei einem Cache Miss.
• Verhalten bei nicht verfügbarem Redis.
• Schutz vor einer Thundering Herd.
• Welche Daten niemals gecacht werden dürfen.

Fehler	Sicheres Cache-Verhalten
Key fehlt	Neu berechnen oder aus der Source of Truth lesen
Redis nicht verfügbar	Mit Rate-Schutz auf die Source of Truth ausweichen
Veralteter Eintrag	Ablaufen lassen oder invalidieren
Änderung der Serialisierung	Key-Namespace versionieren
Speicherdruck	Zuerst wiederherstellbare Daten evicten
Hot Key	Local Cache, Sharding oder Request Coalescing hinzufügen

Mache nicht die gesamte Anwendung ausschließlich deshalb nicht verfügbar, weil ein optionaler Cache ausgefallen ist. Verwende begrenzte Timeouts und Fallback-Pfade. Verberge andererseits nicht alle Fehler: Ein anhaltender Cache-Ausfall kann die Source Database überlasten.

Was ändert sich, wenn Redis als Job-Queue verwendet wird?

Eine Queue repräsentiert ausstehende Arbeit. Daher muss die Anwendung Zustellungs- und Recovery-Semantik definieren. Redis selbst ist ein Data-Structure-Server; die Garantien hängen von der Queue-Library und dem Worker-Protokoll ab.

Lege Folgendes fest:

1. Wann gilt ein Job als angenommen?
2. Wann wird er bestätigt?
3. Was passiert, wenn ein Worker nach der Ausführung des Seiteneffekts, aber vor der Bestätigung abstürzt?
4. Wie werden Retries verzögert und begrenzt?
5. Wohin werden dauerhaft fehlgeschlagene Jobs verschoben?
6. Wie wird eine doppelte Ausführung sicher gemacht?
7. Wie wird die Queue-Tiefe überwacht?
8. Kann der Job-Payload rekonstruiert werden?

Baue idempotente Worker. Eine Zahlungsbuchung, eine E-Mail oder ein Datenimport kann nach einem Fehler mehr als einmal zugestellt werden. Verwende einen fachlichen Idempotency Key und speichere den Abschluss in der Source-of-Truth-Datenbank.

Trenne Queue-Namen nach Workload und Priorität. Ein langsamer Media-Job darf nicht die Verarbeitung von Passwortzurücksetzungen oder Webhooks blockieren. Vermeide Secrets in Job-Payloads, wenn eine Referenz-ID ausreicht.

Ein **Redis-Cache- und Queue-**Deployment sollte dokumentieren, welche Keys verwerfbar sind und welche geschäftliche Arbeit repräsentieren.

Wie verbindet privates Networking Services mit Redis?

Aktiviere das Projektnetzwerk:

dockup network enable production --json

Der Redis-Service ist über seinen stabilen Hostnamen <slug>.internal von Services im selben Projekt erreichbar. Redeploye die Anwendung, damit Dockup die internen Verbindungsvariablen injizieren kann.

Um Redis ausschließlich privat verfügbar zu machen:

dockup db private production/app-redis --json

Aktiviere den öffentlichen Listener bei Bedarf wieder:

dockup db private production/app-redis --off --json

Privates Networking entfernt den Pfad über das öffentliche Internet für Datenverkehr innerhalb desselben Projekts, ersetzt aber keine Authentifizierung. Halte die Redis-Verbindungsdaten geheim und beschränke, welche Services sie erhalten.

Verschiedene Projekte können nicht auf das private Netzwerk des jeweils anderen zugreifen. Diese Grenze kann nützlich sein, wenn Produktion und Staging keine Cache-Keys oder Queue-Arbeit gemeinsam nutzen dürfen.

Siehe privates Networking und interne Domains für das vollständige Modell.

Wie sollten sich Redis-Fehler auf die Anwendung auswirken?

Klassifiziere den Workload, bevor du Recovery-Code schreibst.

Workload	Verlusttoleranz	Reaktion auf Ausfall
HTML-Fragment-Cache	Hoch	Aus der Source of Truth neu aufbauen
Session Store	Niedrig bis mittel	Nutzer können abgemeldet werden; Fallback entwerfen
Rate-Limit-Zähler	Richtlinienabhängig	Explizit Fail Open oder Fail Closed verwenden
Job-Queue	Niedrig	Keine neuen Jobs annehmen oder anderweitig persistieren
Distributed Lock	Für kritische Abschnitte sehr niedrig	Fencing/Idempotency verwenden
Feature-Cache	Hoch	Standardwert oder Source verwenden

Ein Cache-Client sollte nicht unbegrenzt Retries ausführen. Lange Retry-Zeiten können alle Application Worker belegen und aus einem Redis-Vorfall einen vollständigen Ausfall machen. Queue-Worker sollten Backoff verwenden, fehlgeschlagene Arbeit sichtbar machen und nach einer definierten Richtlinie stoppen.

Überprüfe die Redis-Größe und die Runtime-Logs der konsumierenden Anwendung:

dockup db size production/app-redis --json
dockup logs production/api --json

Ein Größenwachstum kann auf fehlende Ablaufzeiten, eine unkontrolliert wachsende Queue-Tiefe, übergroße Payloads oder verwaiste Namespaces hinweisen. Behandle einen Datenbankneustart nicht als erste Reaktion auf Application-Timeouts. Prüfe zuerst Konfiguration, Networking und das Verhalten des Clients.

Wie passen Backup, Migration und Monitoring zu Redis?

Dockup stellt den Backup-Workflow für Managed Databases bereit:

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

Ob ein Redis-Backup das Recovery-Ziel des Workloads erfüllt, hängt davon ab, welche Bedeutung die Daten haben. Für einen Cache ist ein Backup möglicherweise unnötig. Ein Queue-Backup kann trotzdem Arbeit verlieren, die nach dem Backup-Zeitpunkt angenommen wurde. Geschäftskritische Jobs sollten nach Möglichkeit außerhalb der Queue über einen wiederherstellbaren Source Record verfügen.

Verschiebe Redis mit folgendem Befehl zwischen Nodes:

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Plane die Auswirkungen der Migration auf Clients und Worker. Stelle vor dem Produktionseinsatz sicher, dass Reconnection-, Retry- und Idempotency-Verhalten funktionieren.

Überwache zusätzlich zur Datenbankgröße Metriken auf Anwendungsebene:

• Cache-Hit-Rate.
• Miss-Latenz.
• Evictions.
• Queue-Tiefe und Alter des ältesten Jobs.
• Erfolgs-, Retry- und Fehlerzähler von Jobs.
• Worker-Concurrency.
• Redis-Verbindungsfehler.
• Payload-Größe.

Dockup misst den CPU-, RAM- und Festplattenverbrauch pro Minute im Verhältnis zum Guthaben des Plans. Der empfohlene Pro-Plan kostet 20 $ pro Monat und enthält ein Nutzungsguthaben von 20 $. Für Kapazitätsentscheidungen sollten jedoch die Workload-Metriken ausschlaggebend sein – nicht der Name des Plans.

Wie sieht eine sichere Redis-Produktions-Checkliste aus?

Prüfe vor dem Launch:

1. Exaktes Ziel im Format project/db.
2. Verantwortlichkeiten von Cache und Queue sind dokumentiert.
3. Die Connection URL ist als maskiertes Secret hinterlegt.
4. Die Richtlinie für privates Networking ist festgelegt.
5. Jeder Cache verfügt über eine TTL oder eine explizite Invalidierung.
6. Queue-Worker sind idempotent.
7. Retry- und Dead-Letter-Verhalten wird vom Queue-System definiert.
8. Alarme für Größe und Queue-Tiefe sind eingerichtet.
9. Wert und Einschränkungen von Backups sind bekannt.
10. Neustarts und Migrationen erfordern eine Freigabe.

Beispiel für die Trennung von Cache und Queue

Eine kleine Anwendung kann bei einem risikoarmen Workload mit einer Redis-Datenbank beginnen, sollte aber eindeutige Key-Präfixe verwenden:

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

Wenn der Workload wächst, trenne den kritischen Queue-Zustand vom aggressiv evicten Cache-Zustand. Das ist eine betriebliche Grenze und nicht nur eine Frage der Namensgebung.

Ein erfolgreiches **Redis-Cache- und Queue-**Design macht das Verhalten der Anwendung vorhersehbar, wenn Redis schnell, langsam, leer oder nicht verfügbar ist.

Für relationale Vorgänge mit der Source of Truth siehe Managed PostgreSQL. Für umfassendere Kapazitätsentscheidungen siehe Strategien zur Datenbank-Skalierung. Verwende die Dockup-CLI-Referenz für aktuelle Datenbankbefehle.

Entwicklung von Keys und Payloads definieren

Cache- und Queue-Daten überdauern einen einzelnen Application Process. Ein neues Release kann während eines Blue-Green-Cutovers Keys lesen, die vom vorherigen Release geschrieben wurden. Versioniere Key-Namespaces und Job-Payloads, damit beide Versionen parallel existieren können.

Füge bei Queues eine Payload-Version hinzu und stelle sicher, dass Worker mindestens die Versionen verarbeiten können, die noch warten könnten. Ein Rollback des Deployments kann alten Code wiederherstellen, während Jobs im neuen Format in Redis verbleiben. Ohne Kompatibilität kann ein Application Rollback die Fehlerquote erhöhen.

Ressourcendruck gezielt testen

Teste in einer Nicht-Produktionsumgebung fehlende Keys, langsame Redis-Antworten, Verbindungsabbrüche, Queue-Rückstau, doppelte Zustellung und einen vollen oder nahezu vollen Speicher. Beobachte, ob die Anwendung Fail Open, Fail Closed, Retries oder eine Überlastung einer anderen Abhängigkeit verursacht.

Ein **Redis-Cache- und Queue-**Runbook sollte Grenzen für Retry-Versuche und Concurrency festlegen. Unbegrenzte Retry-Schleifen können alle Worker belegen und die Wiederherstellung schwieriger machen als den ursprünglichen Vorfall.

Einen Recovery-Pfad zur Source of Truth beibehalten

Speichere für kritische Jobs genügend Zustand in der primären Datenbank, um die Arbeit nach einem Redis-Verlust zu rekonstruieren. Eine Queue sollte die Verarbeitung beschleunigen und nicht zum einzigen Nachweis dafür werden, dass eine Kundenaktion stattgefunden hat.

Mit einem überprüfbaren Deployment starten

Stelle Redis in einem Nicht-Produktionsprojekt bereit, teste den Cache-Fallback und die doppelte Zustellung von Jobs und mache die Fehlerstrategie explizit, bevor du kritische Arbeit darüber leitest.

Kostenlos auf app.dockup.ai starten. Der Free-Plan kostet 0 $ pro Monat, enthält ein Startguthaben von 10 $ und unterstützt einen Workspace, drei Datenbanken und drei Deployments.

FAQ

Kann Dockup Managed Redis erstellen?

Ja. Verwende den Befehl zum Erstellen einer Managed Database mit dem Typ redis und verbinde anschließend die Anwendung über die zurückgegebenen Verbindungsdaten, die als Secret gespeichert werden.

Sollten Cache- und Queue-Daten dieselbe Redis-Instanz verwenden?

Bei einem kleinen, risikoarmen Workload ist das möglich. Eine Trennung ist jedoch sicherer, wenn Cache-Eviction und die kritische Aufbewahrung von Queue-Einträgen unterschiedliche Anforderungen an Verfügbarkeit und Speicher haben.

Garantiert Redis, dass ein in die Queue eingereihter Job genau einmal ausgeführt wird?

Nein. Von einer allgemeinen Exactly-once-Garantie sollte nicht ausgegangen werden. Die Zustellungssemantik hängt von der Queue-Library und dem Worker-Design ab. Seiteneffekte sollten daher idempotent sein.

Kann Redis das private Networking von Dockup verwenden?

Ja. Aktiviere das Projektnetzwerk, redeploye die konsumierenden Services, damit sie interne Variablen erhalten, und mache die Redis-Datenbank bei Bedarf ausschließlich privat verfügbar.

Reicht ein Redis-Backup für eine kritische Job-Queue aus?

Nicht unbedingt. Es repräsentiert einen Zeitpunkt und enthält möglicherweise keine später angenommene Arbeit. Bewahre wiederherstellbare Source Records auf und definiere eine Recovery auf Anwendungsebene.