Workload di cache e queue Redis su Dockup

I workload di cache e queue Redis possono usare lo stesso servizio Redis gestito, ma hanno requisiti di correttezza diversi. Una cache può in genere essere ricostruita dopo una perdita. Una queue può rappresentare attività che non devono essere scartate silenziosamente o elaborate due volte.

Dockup esegue il provisioning di Redis come database gestito, fornisce operazioni di dimensionamento e consultazione dei log, supporta i workflow di backup e migrazione dei nodi e può connettere il database ai servizi applicativi tramite il networking privato del progetto.

Come si esegue il provisioning di Redis gestito?

Crea Redis nel workspace selezionato:

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

Verifica il target del database:

dockup db list --json

Conserva i dati di connessione restituiti fuori dal controllo del codice sorgente e collegali al servizio che li utilizza come secret:

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

dockup deploy production/api --wait --json

Il redeploy crea un nuovo container applicativo con l'ambiente aggiornato. Il riavvio del vecchio container non applica un nuovo valore desiderato che è stato salvato.

Usa database o istanze Redis separate quando il comportamento di eviction della cache e la retention di una queue critica non devono competere per la stessa memoria. L'isolamento semplifica anche la diagnosi degli incidenti e il controllo degli accessi.

Quando è opportuno usare Redis come cache?

Una cache riduce il lavoro ripetuto o la latenza memorizzando dati derivati. La source of truth rimane altrove, in genere in PostgreSQL, MySQL, MongoDB, un'API esterna o un calcolo deterministico.

Una progettazione solida della cache definisce:

• Formato e namespace delle cache key.
• Time to live.
• Staleness massima accettabile.
• Trigger di invalidazione.
• Comportamento in caso di miss.
• Comportamento quando Redis non è disponibile.
• Protezione dal thundering herd.
• Dati che non devono mai essere messi in cache.

Errore	Comportamento sicuro della cache
Chiave mancante	Ricalcolare o leggere dalla source of truth
Redis non disponibile	Degradare alla source of truth con protezione del rate
Entry obsoleta	Farla scadere o invalidarla
Modifica della serializzazione	Versionare il namespace delle chiavi
Pressione sulla memoria	Evictare per primi i dati ricostruibili
Hot key	Aggiungere una cache locale, lo sharding o il request coalescing

Non rendere indisponibile l'intera applicazione solo perché una cache opzionale è down. Usa timeout limitati e percorsi di fallback. D'altra parte, non nascondere tutti gli errori: un'interruzione prolungata della cache può sovraccaricare il database sorgente.

Cosa cambia quando Redis viene usato come job queue?

Una queue rappresenta lavoro in attesa, quindi l'applicazione deve definire la semantica di consegna e recupero. Redis è un data structure server; le garanzie dipendono dalla libreria della queue e dal protocollo dei worker.

Decidi:

1. Quando un job viene considerato accettato?
2. Quando viene riconosciuto?
3. Cosa succede se un worker va in crash dopo aver eseguito il side effect ma prima del riconoscimento?
4. Come vengono ritardati e limitati i retry?
5. Dove finiscono i job che falliscono definitivamente?
6. Come si rende sicura l'esecuzione duplicata?
7. Come viene osservata la profondità della queue?
8. È possibile ricostruire il payload del job?

Progetta worker idempotenti. Un pagamento, un'email o un'importazione di dati potrebbe essere consegnato più di una volta dopo un errore. Usa una business idempotency key e registra il completamento nel database che funge da source of truth.

Separa i nomi delle queue in base al workload e alla priorità. Un job multimediale lento non dovrebbe impedire l'elaborazione dei reset della password o dei webhook. Evita di inserire secret nei payload dei job quando è sufficiente un ID di riferimento.

Un deployment di cache e queue Redis dovrebbe documentare quali chiavi sono eliminabili e quali rappresentano lavoro aziendale.

In che modo il networking privato connette i servizi a Redis?

Abilita il networking del progetto:

dockup network enable production --json

Il servizio Redis diventa raggiungibile tramite il suo hostname stabile <slug>.internal dai servizi dello stesso progetto. Esegui il redeploy dell'applicazione affinché Dockup possa iniettare le variabili di connessione interne.

Per rendere Redis accessibile solo privatamente:

dockup db private production/app-redis --json

Ripristina il listener pubblico quando necessario:

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

Il networking privato rimuove il percorso su Internet pubblico per il traffico tra servizi dello stesso progetto, ma non sostituisce l'autenticazione. Mantieni segreti i dati di connessione Redis e limita i servizi che li ricevono.

Progetti diversi non possono raggiungere la rete privata degli altri progetti. Questo confine può essere utile quando produzione e staging non devono condividere cache key o lavori in queue.

Consulta networking privato e domini interni per il modello completo.

In che modo gli errori di Redis dovrebbero influire sull'applicazione?

Classifica il workload prima di scrivere il codice di recovery.

Workload	Tolleranza alla perdita	Risposta all'interruzione
Cache di frammenti HTML	Alta	Ricostruire dalla source of truth
Session store	Da bassa a media	Potrebbe disconnettere gli utenti; progettare un fallback
Contatori di rate limit	Dipende dalla policy	Fail open o fail closed in modo esplicito
Job queue	Bassa	Smettere di accettare lavori o persisterli altrove
Distributed lock	Molto bassa per sezioni critiche	Usare fencing/idempotency
Feature cache	Alta	Usare il valore predefinito o la source of truth

Un client Redis non dovrebbe ritentare all'infinito. Retry prolungati possono consumare ogni worker dell'applicazione e trasformare un incidente Redis in un'interruzione completa. I worker delle queue dovrebbero applicare il backoff, rendere visibile il lavoro fallito e fermarsi dopo una policy definita.

Controlla la dimensione di Redis e i runtime log dell'applicazione che lo utilizza:

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

Una crescita delle dimensioni può indicare expiration mancanti, una profondità della queue fuori controllo, payload troppo grandi o namespace abbandonati. Non considerare il riavvio di un database come prima risposta ai timeout dell'applicazione; controlla prima configurazione, networking e comportamento del client.

Come si integrano backup, migrazione e monitoraggio con Redis?

Dockup espone il workflow di backup del database gestito:

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

Il fatto che un backup Redis soddisfi l'obiettivo di recovery del workload dipende dal significato dei dati. Un backup della cache potrebbe essere superfluo. Un backup della queue potrebbe comunque perdere il lavoro accettato dopo il punto del backup. Quando possibile, i job critici per il business dovrebbero avere un record sorgente recuperabile al di fuori della queue.

Sposta Redis tra i nodi con:

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

Pianifica l'impatto della migrazione su client e worker. Verifica che il comportamento di riconnessione, retry e idempotency funzioni prima di procedere in produzione.

Monitora le metriche a livello applicativo oltre alla dimensione del database:

• Cache hit ratio.
• Latenza dei miss.
• Eviction.
• Profondità della queue e anzianità del job più vecchio.
• Conteggi di job completati, ritentati e falliti.
• Concorrenza dei worker.
• Errori di connessione Redis.
• Dimensione dei payload.

Dockup misura il consumo di CPU, RAM e disco ogni minuto rispetto alla disponibilità del piano. Il piano Pro consigliato costa $20 al mese e include $20 di credito per l'utilizzo, ma sono le metriche del workload — non il nome del piano — a dover guidare le decisioni sulla capacità.

Qual è una checklist sicura per Redis in produzione?

Prima del lancio, verifica:

1. Target project/db esatto.
2. Le responsabilità di cache e queue sono documentate.
3. L'URL di connessione è un secret mascherato.
4. La policy di networking privato è stata decisa.
5. Ogni cache ha un TTL o un'invalidazione esplicita.
6. I worker della queue sono idempotenti.
7. Il comportamento di retry e dead-letter è definito dal sistema di queue.
8. Esistono alert per dimensione e profondità della queue.
9. Il valore e i limiti del backup sono chiari.
10. Riavvio e migrazione richiedono un'approvazione.

Esempio di separazione tra cache e queue

Una piccola applicazione può iniziare con un unico database Redis quando il rischio è basso, ma deve usare prefissi chiari per le chiavi:

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

Con la crescita del workload, separa lo stato delle queue critiche dallo stato della cache sottoposto ad eviction aggressiva. Si tratta di un confine operativo, non di una semplice preferenza di naming.

Una progettazione efficace di cache e queue Redis rende prevedibile il comportamento dell'applicazione quando Redis è veloce, lento, vuoto o non disponibile.

Per le operazioni relazionali sulla source of truth, consulta PostgreSQL gestito. Per una panoramica più ampia delle opzioni di capacità, consulta strategie di scaling dei database. Usa il riferimento della CLI di Dockup per i comandi database aggiornati.

Definisci l'evoluzione di chiavi e payload

I dati di cache e queue sopravvivono a un singolo processo applicativo. Una nuova release potrebbe leggere chiavi scritte dalla release precedente durante un cutover blue-green. Versiona i namespace delle chiavi e i payload dei job, così entrambe le versioni possono coesistere.

Per le queue, includi una versione del payload e mantieni i worker in grado di elaborare almeno le versioni che potrebbero essere ancora in attesa. Un rollback del deployment può ripristinare il vecchio codice mentre i job nel nuovo formato rimangono in Redis. Senza compatibilità, il rollback dell'applicazione può aumentare gli errori.

Testa deliberatamente la pressione sulle risorse

In un ambiente non di produzione, testa chiavi mancanti, risposte Redis lente, reset delle connessioni, backlog della queue, consegna duplicata e condizioni di memoria piena o quasi piena. Osserva se l'applicazione esegue fail open, fail closed, retry o sovraccarica un'altra dipendenza.

Un runbook di cache e queue Redis dovrebbe impostare limiti sul numero di retry e sulla concorrenza. Loop di retry illimitati possono consumare tutti i worker e rendere il recovery più difficile dell'incidente originale.

Mantieni un percorso di recovery dalla source of truth

Per i job critici, salva nel database primario dati sufficienti a ricostruire il lavoro dopo una perdita di Redis. Una queue dovrebbe accelerare l'elaborazione, non diventare l'unico record del fatto che si è verificata un'azione del cliente.

Inizia con un deployment verificabile

Esegui il provisioning di Redis in un progetto non di produzione, testa il fallback della cache e la consegna duplicata dei job e rendi esplicita la policy di errore prima di instradare il lavoro critico.

Inizia gratuitamente su app.dockup.ai. Il piano Free costa $0 al mese, include $10 di credito iniziale e supporta un workspace, tre database e tre deployment.

FAQ

Dockup può creare Redis gestito?

Sì. Usa il comando per creare un database gestito con il tipo redis, quindi collega l'applicazione usando i dati di connessione restituiti e memorizzati come secret.

I dati di cache e queue dovrebbero condividere un'unica istanza Redis?

È possibile per un workload piccolo e a basso rischio, ma la separazione è più sicura quando eviction della cache e retention della queue critica hanno requisiti diversi di disponibilità e memoria.

Redis garantisce che un job in queue venga eseguito esattamente una volta?

Non si dovrebbe presumere alcuna garanzia generale di esecuzione exactly-once. La semantica di consegna dipende dalla libreria della queue e dalla progettazione dei worker, quindi rendi idempotenti i side effect.

Redis può usare il networking privato di Dockup?

Sì. Abilita la rete del progetto, esegui il redeploy dei servizi che consumano Redis per ottenere le variabili interne e, facoltativamente, rendi il database Redis accessibile solo privatamente.

Un backup Redis è sufficiente per una job queue critica?

Non necessariamente. Rappresenta un punto nel tempo e potrebbe non includere il lavoro accettato più recentemente. Mantieni record sorgente recuperabili e definisci il recovery dei job a livello applicativo.