Redis-cache og queue-workloads på Dockup

Redis cache and queue-workloads kan bruge den samme managed Redis-service, men de har forskellige krav til korrekthed. En cache kan som regel genopbygges efter datatab. En queue kan repræsentere arbejde, der ikke må kasseres ubemærket eller behandles to gange.

Dockup klargør Redis som en managed database, giver adgang til størrelses- og logoperationer, understøtter workflows til backup og nodemigrering og kan forbinde databasen med application services via project-private networking.

Hvordan klargør du managed Redis?

Opret Redis i det valgte workspace:

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

Bekræft databasens target:

dockup db list --json

Opbevar de returnerede connection-oplysninger uden for source control, og tilknyt dem til den service, der bruger dem, som en secret:

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

dockup deploy production/api --wait --json

Ved redeploy oprettes en ny application container med det opdaterede environment. En genstart af den gamle container anvender ikke en ny lagret desired value.

Brug separate Redis-databaser eller instanser, når cache eviction-adfærd og kritisk queue retention ikke bør konkurrere om den samme hukommelse. Isolation gør det også nemmere at diagnosticere incidents og styre adgang.

Hvornår bør Redis bruges som cache?

En cache reducerer gentaget arbejde eller latency ved at gemme afledte data. Kilden til sandheden findes fortsat et andet sted, typisk PostgreSQL, MySQL, MongoDB, et eksternt API eller en deterministisk beregning.

Et solidt cache-design definerer:

• Format og namespace for cache keys.
• Time to live.
• Maksimalt acceptabel stale data.
• Invalidation trigger.
• Adfærd ved cache miss.
• Adfærd, når Redis ikke er tilgængelig.
• Beskyttelse mod en thundering herd.
• Hvilke data der aldrig må caches.

Fejl	Sikker cache-adfærd
Key mangler	Beregn igen, eller læs fra kilden til sandheden
Redis er ikke tilgængelig	Fald tilbage til kilden med rate protection
Stale entry	Udløb eller invalidér
Ændring i serialisering	Versionér key namespace
Pres på hukommelsen	Evict data, der kan genopbygges, først
Hot key	Tilføj local cache, sharding eller request coalescing

Gør ikke hele applikationen utilgængelig, alene fordi en optional cache er nede. Brug bounded timeouts og fallback paths. På den anden side må du ikke skjule alle fejl; et længerevarende cache-nedbrud kan overbelaste source-databasen.

Hvad ændrer sig, når Redis bruges som job queue?

En queue repræsenterer ventende arbejde, så applikationen skal definere delivery- og recovery-semantik. Redis er i sig selv en data structure-server; garantierne afhænger af queue-biblioteket og worker-protokollen.

Beslut:

1. Hvornår betragtes et job som accepted?
2. Hvornår bliver det acknowledged?
3. Hvad sker der, hvis en worker crasher efter at have udført sideeffekten, men før acknowledgment?
4. Hvordan forsinkes og begrænses retries?
5. Hvor ender jobs, der permanent fejler?
6. Hvordan gøres duplicate execution sikker?
7. Hvordan observeres queue depth?
8. Kan job-payloaden rekonstrueres?

Byg idempotente workers. En betalingscapture, e-mail eller dataimport kan blive leveret mere end én gang efter en fejl. Brug en business idempotency key, og registrér completion i source-of-truth-databasen.

Adskil queue names efter workload og prioritet. Et langsomt media-job bør ikke blokere password-reset- eller webhook-behandling. Undgå at placere secrets i job-payloads, når et reference-ID er tilstrækkeligt.

En Redis cache and queue-deployment bør dokumentere, hvilke keys der kan kasseres, og hvilke der repræsenterer forretningsarbejde.

Hvordan forbinder private networking services med Redis?

Aktivér project networking:

dockup network enable production --json

Redis-servicen kan derefter nås via dens stabile <slug>.internal-hostname fra services i det samme projekt. Redeploy applikationen, så Dockup kan injecte de interne connection variables.

Gør Redis private-only:

dockup db private production/app-redis --json

Gendan den offentlige listener, når det er nødvendigt:

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

Private networking fjerner internetforbindelsen for trafik mellem services i det samme projekt, men erstatter ikke authentication. Hold Redis connection-oplysningerne hemmelige, og begræns, hvilke services der modtager dem.

Forskellige projekter kan ikke tilgå hinandens private network. Denne grænse kan være nyttig, når production og staging ikke må dele cache keys eller queue work.

Se private networking and internal domains for den fulde model.

Hvordan bør Redis-fejl påvirke applikationen?

Klassificér workloaden, før du skriver recovery-kode.

Workload	Tolerance over for datatab	Reaktion ved outage
HTML fragment-cache	Høj	Genopbyg fra kilden
Session store	Lav til middel	Brugere kan blive logget ud; design en fallback
Rate-limit counters	Afhænger af policy	Vælg eksplicit fail open eller fail closed
Job queue	Lav	Stop med at acceptere jobs, eller persistér dem et andet sted
Distributed lock	Meget lav for kritiske sektioner	Brug fencing/idempotency
Feature cache	Høj	Brug en default value eller kilden

En cache-client bør ikke retry uendeligt. Lange retries kan optage alle application workers og forvandle en Redis-incident til et komplet outage. Queue workers bør backoffe, synliggøre fejlet arbejde og stoppe efter en defineret policy.

Undersøg Redis-størrelsen og runtime logs fra den applikation, der bruger Redis:

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

Vækst i størrelse kan være tegn på manglende expiration, runaway queue depth, for store payloads eller forladte namespaces. Betragt ikke en restart af databasen som det første svar på application timeouts; kontrollér først configuration, networking og client-adfærd.

Hvordan hænger backup, migration og monitoring sammen for Redis?

Dockup stiller et workflow til backup af managed databases til rådighed:

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

Om en Redis-backup opfylder workloadens recovery-mål, afhænger af, hvad dataene betyder. En cache-backup kan være unødvendig. En queue-backup kan stadig miste arbejde, der blev accepteret efter backup-punktet. Forretningskritiske jobs bør så vidt muligt have en recoverable source-record uden for queuen.

Flyt Redis mellem nodes med:

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

Planlæg migrationens påvirkning af clients og workers. Bekræft, at reconnection-, retry- og idempotency-adfærd fungerer, før du migrerer i production.

Overvåg metrics på application-niveau ud over databasens størrelse:

• Cache hit ratio.
• Miss latency.
• Evictions.
• Queue depth og alderen på det ældste job.
• Antal successfulde, retryede og fejlede jobs.
• Worker concurrency.
• Redis connection errors.
• Payload size.

Dockup måler CPU-, RAM- og diskforbrug pr. minut op mod planens balance. Den anbefalede Pro-plan koster $20 om måneden og inkluderer $20 i usage credit, men det er workload-metrics – ikke planens navn – der bør styre beslutninger om kapacitet.

Hvad indeholder en sikker Redis production-checkliste?

Kontrollér følgende før launch:

1. Det præcise project/db-target.
2. Cache- og queue-ansvarsområder er dokumenteret.
3. Connection URL er en masked secret.
4. Policy for private networking er besluttet.
5. Alle caches har TTL eller eksplicit invalidation.
6. Queue workers er idempotente.
7. Retry- og dead-letter-adfærd er defineret af queue-systemet.
8. Der findes alarmer for størrelse og queue depth.
9. Backupens værdi og begrænsninger er forstået.
10. Restart og migration kræver approval.

Eksempel på adskillelse af cache og queue

En lille applikation kan begynde med én Redis-database, når risikoen er lav, men bruge tydelige key prefixes:

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

Efterhånden som workloaden vokser, bør kritisk queue state adskilles fra cache state, der evictes aggressivt. Det er en operationel grænse, ikke blot et spørgsmål om navngivning.

Et vellykket Redis cache and queue-design gør applikationens adfærd forudsigelig, når Redis er hurtig, langsom, tom eller utilgængelig.

Se managed PostgreSQL for operations med relationelle source-of-truth-data. Se database scaling strategies for bredere valg af kapacitet. Brug Dockup CLI reference for aktuelle database commands.

Definér udviklingen af keys og payloads

Cache- og queue-data lever længere end en enkelt application process. En ny release kan læse keys, som den forrige release skrev, under en blue-green cutover. Versionér key namespaces og job payloads, så begge versioner kan eksistere side om side.

For queues skal du inkludere en payload-version og sørge for, at workers kan behandle mindst de versioner, der stadig kan være i kø. En rollback af en deployment kan gendanne gammel kode, mens jobs i det nye format stadig ligger i Redis. Uden compatibility kan en application rollback øge antallet af fejl.

Test resource pressure med vilje

Test i et non-production-miljø manglende keys, langsomme Redis-responses, connection resets, queue backlog, duplicate delivery samt en fuld eller næsten fuld memory condition. Observer, om applikationen failer open, failer closed, retrier eller overbelaster en anden dependency.

En Redis cache and queue-runbook bør sætte grænser for retry-forsøg og concurrency. Ubegrænsede retry loops kan optage alle workers og gøre recovery vanskeligere end den oprindelige incident.

Bevar en recovery path til kilden til sandheden

For kritiske jobs skal du gemme tilstrækkelig state i den primære database til at kunne rekonstruere arbejdet efter tab af Redis. En queue bør accelerere behandlingen, ikke blive den eneste registrering af, at en kundehandling har fundet sted.

Start med en deployment, der kan verificeres

Klargør Redis i et non-production-projekt, test cache fallback og duplicate job delivery, og gør failure policy eksplicit, før du sender kritisk arbejde gennem systemet.

Start gratis på app.dockup.ai. Free-planen koster $0 om måneden, inkluderer $10 i starting credit og understøtter ét workspace, tre databaser og tre deployments.

FAQ

Kan Dockup oprette managed Redis?

Ja. Brug kommandoen til oprettelse af en managed database med typen redis, og forbind derefter applikationen med de returnerede connection-oplysninger, der er gemt som en secret.

Bør cache- og queue-data dele én Redis-instans?

Det kan de i en lille workload med lav risiko, men adskillelse er sikrere, når cache eviction og kritisk queue retention har forskellige krav til availability og memory.

Garanterer Redis, at et queued job køres præcis én gang?

Nej, der bør ikke antages en generel exactly-once-garanti. Delivery-semantikken afhænger af queue-biblioteket og worker-designet, så sideeffekter skal gøres idempotente.

Kan Redis bruge Dockups private networking?

Ja. Aktivér project network, redeploy de services, der bruger Redis, så de interne variables bliver tilgængelige, og gør eventuelt Redis-databasen private-only.

Er en Redis-backup tilstrækkelig til en kritisk job queue?

Ikke nødvendigvis. Den repræsenterer et bestemt tidspunkt og indeholder muligvis ikke nyere accepteret arbejde. Bevar recoverable source records, og definér application-level job recovery.