Redis-cache- en queue-workloads op Dockup

Redis-cache- en queue-workloads kunnen dezelfde managed Redis-service gebruiken, maar stellen verschillende eisen aan correctheid. Een cache kan meestal na verlies opnieuw worden opgebouwd. Een queue kan werk vertegenwoordigen dat niet stilzwijgend mag worden verwijderd of twee keer mag worden verwerkt.

Dockup provisiont Redis als managed database, biedt bewerkingen voor grootte en logs, ondersteunt workflows voor back-ups en nodemigratie en kan de database via project-private networking verbinden met applicatieservices.

Hoe provision je managed Redis?

Maak Redis aan in de geselecteerde workspace:

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

Controleer het database-doel:

dockup db list --json

Sla de geretourneerde connectiongegevens buiten source control op en koppel ze als secret aan de service die ze gebruikt:

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

dockup deploy production/api --wait --json

Bij het redeployen wordt een nieuwe applicatiecontainer aangemaakt met de bijgewerkte environment. Een herstart van de oude container past een nieuw opgeslagen gewenste waarde niet toe.

Gebruik afzonderlijke Redis-databases of -instanties wanneer cache-eviction en kritieke queue-retentie niet met elkaar om hetzelfde geheugen moeten concurreren. Isolatie vereenvoudigt ook incidentdiagnose en toegangsbeheer.

Wanneer moet je Redis als cache gebruiken?

Een cache vermindert herhaald werk of latency door afgeleide gegevens op te slaan. De source of truth blijft elders, meestal in PostgreSQL, MySQL, MongoDB, een externe API of een deterministische berekening.

Een solide cache-ontwerp definieert:

• Indeling en namespace van cache keys.
• Time to live.
• Maximaal aanvaardbare veroudering.
• Trigger voor invalidatie.
• Gedrag bij een cache miss.
• Gedrag wanneer Redis niet beschikbaar is.
• Bescherming tegen een thundering herd.
• Welke gegevens nooit mogen worden gecachet.

Fout	Veilig cachegedrag
Key ontbreekt	Opnieuw berekenen of de source of truth lezen
Redis niet beschikbaar	Terugvallen op de source met rate protection
Verouderde entry	Laten verlopen of invalideren
Wijziging in serialisatie	Key-namespace van een versie voorzien
Geheugendruk	Eerst opnieuw opbouwbare gegevens evicten
Hot key	Local cache, sharding of request coalescing toevoegen

Maak de volledige applicatie niet onbeschikbaar alleen omdat een optionele cache uitvalt. Gebruik begrensde time-outs en fallback-paden. Verberg daarentegen niet alle fouten; een langdurige cache-uitval kan de brondatabase overbelasten.

Wat verandert er wanneer Redis als job queue wordt gebruikt?

Een queue vertegenwoordigt werk dat nog moet worden uitgevoerd. Daarom moet de applicatie delivery- en recoverysemantiek definiëren. Redis is zelf een data-structureserver; de garanties zijn afhankelijk van de queue library en het workerprotocol.

Bepaal:

1. Wanneer wordt een job als geaccepteerd beschouwd?
2. Wanneer wordt de job acknowledged?
3. Wat gebeurt er als een worker crasht nadat het side effect is uitgevoerd maar vóór de acknowledgment?
4. Hoe worden retries vertraagd en begrensd?
5. Waar gaan permanent mislukte jobs naartoe?
6. Hoe wordt dubbele uitvoering veilig gemaakt?
7. Hoe wordt de queue depth geobserveerd?
8. Kan de job-payload opnieuw worden opgebouwd?

Bouw idempotente workers. Een payment capture, e-mail of data-import kan na een fout meer dan één keer worden afgeleverd. Gebruik een business-idempotency key en leg de voltooiing vast in de source-of-truth-database.

Scheid queuenamen per workload en prioriteit. Een trage mediajob mag de verwerking van password resets of webhooks niet uithongeren. Plaats geen secrets in job-payloads wanneer een reference ID volstaat.

Een Redis-cache- en queue-deployment moet documenteren welke keys wegwerpbaar zijn en welke bedrijfswerk vertegenwoordigen.

Hoe verbindt private networking services met Redis?

Schakel projectnetwerken in:

dockup network enable production --json

De Redis-service wordt bereikbaar via de stabiele hostname <slug>.internal vanuit services in hetzelfde project. Redeploy de applicatie zodat Dockup de interne connection variables kan injecteren.

Maak Redis alleen privé toegankelijk:

dockup db private production/app-redis --json

Herstel de publieke listener wanneer dat nodig is:

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

Private networking verwijdert de route via het openbare internet voor verkeer binnen hetzelfde project, maar vervangt authenticatie niet. Houd de Redis-connectiongegevens geheim en beperk welke services ze ontvangen.

Verschillende projecten kunnen elkaars private network niet bereiken. Deze grens kan nuttig zijn wanneer production en staging geen cache keys of queuewerk mogen delen.

Zie private networking en interne domeinen voor het volledige model.

Welke invloed moeten Redis-fouten op de applicatie hebben?

Classificeer de workload voordat je recoverycode schrijft.

Workload	Tolerantie voor verlies	Reactie bij uitval
HTML-fragmentcache	Hoog	Opnieuw opbouwen vanuit de source
Session store	Laag tot gemiddeld	Kan gebruikers uitloggen; ontwerp een fallback
Rate-limit counters	Afhankelijk van beleid	Expliciet fail open of fail closed
Job queue	Laag	Stop met accepteren of persisteer elders
Distributed lock	Zeer laag voor kritieke secties	Gebruik fencing/idempotency
Feature cache	Hoog	Gebruik een standaardwaarde of de source

Een cacheclient mag niet voor altijd blijven retryen. Lange retries kunnen elke applicatieworker bezighouden en een Redis-incident veranderen in een volledige uitval. Queue-workers moeten back-off toepassen, mislukt werk zichtbaar maken en stoppen volgens een gedefinieerd beleid.

Inspecteer de Redis-grootte en de runtime-logs van de applicatie die Redis gebruikt:

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

Groeiende omvang kan wijzen op ontbrekende expiratie, een onbeheersbare queue depth, te grote payloads of achtergelaten namespaces. Behandel een databaseherstart niet als eerste reactie op application time-outs; controleer eerst de configuratie, networking en het gedrag van de client.

Hoe passen back-ups, migratie en monitoring bij Redis?

Dockup biedt de workflow voor back-ups van managed databases:

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

Of een Redis-back-up voldoet aan de recoverydoelstelling van de workload, hangt af van de betekenis van de gegevens. Een cache-back-up kan overbodig zijn. Een queue-back-up kan nog steeds werk verliezen dat na het back-uppunt is geaccepteerd. Kritieke bedrijfsjobs moeten waar mogelijk buiten de queue een herstelbaar bronrecord hebben.

Verplaats Redis tussen nodes met:

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

Plan de impact van de migratie op clients en workers. Controleer vóór production of reconnecten, retrygedrag en idempotency correct werken.

Monitor naast de databas grootte ook metrics op applicatieniveau:

• Cache hit ratio.
• Latency bij cache misses.
• Evictions.
• Queue depth en leeftijd van de oudste job.
• Aantallen geslaagde, opnieuw uitgevoerde en mislukte jobs.
• Worker-concurrency.
• Redis connection errors.
• Payloadgrootte.

Dockup meet CPU-, RAM- en schijfverbruik per minuut ten opzichte van het saldo van het plan. Het aanbevolen Pro-plan kost $20 per maand en bevat $20 usage credit, maar workloadmetrics — niet de naam van het plan — moeten de capaciteitsbeslissingen bepalen.

Wat is een veilige Redis-checklist voor production?

Controleer vóór de lancering:

1. Het exacte project/db-doel.
2. De verantwoordelijkheden van cache en queue zijn gedocumenteerd.
3. De connection URL is een gemaskeerd secret.
4. Het beleid voor private networking is bepaald.
5. Elke cache heeft een TTL of expliciete invalidatie.
6. Queue-workers zijn idempotent.
7. Retry- en dead-lettergedrag is door het queuesysteem gedefinieerd.
8. Er bestaan alerts voor grootte en queue depth.
9. De waarde en beperkingen van back-ups zijn bekend.
10. Herstarts en migraties vereisen goedkeuring.

Voorbeeld van scheiding tussen cache en queue

Een kleine applicatie kan met één Redis-database beginnen wanneer het risico laag is, maar gebruik duidelijke key prefixes:

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

Naarmate de workload groeit, scheid je de kritieke queue state van cache state die agressief wordt geëvict. Dit is een operationele grens, niet alleen een kwestie van naamgeving.

Een succesvol Redis-cache- en queue-ontwerp maakt het gedrag van de applicatie voorspelbaar wanneer Redis snel, traag, leeg of niet beschikbaar is.

Zie managed PostgreSQL voor relationele source-of-truth-bewerkingen. Zie strategieën voor databasescaling voor bredere capaciteitskeuzes. Gebruik de Dockup CLI reference voor actuele databasecommando's.

Definieer de evolutie van keys en payloads

Cache- en queuedata blijven langer bestaan dan één applicatieproces. Een nieuwe release kan keys lezen die de vorige release tijdens een blue-green cutover heeft geschreven. Geef key namespaces en job-payloads een versie, zodat beide versies naast elkaar kunnen bestaan.

Neem voor queues een payloadversie op en zorg dat workers ten minste de versies kunnen verwerken die nog in de queue kunnen staan. Bij een deployment rollback kan oude code worden hersteld terwijl jobs in het nieuwe formaat in Redis blijven staan. Zonder compatibiliteit kan een rollback van de applicatie het aantal fouten verhogen.

Test resource pressure bewust

Test in een non-productionomgeving ontbrekende keys, trage Redis-responses, verbroken verbindingen, queue backlogs, dubbele aflevering en een volle of bijna volle geheugentoestand. Observeer of de applicatie fail open, fail closed, retryt of een andere dependency overbelast.

Een Redis-cache- en queue-runbook moet limieten instellen voor het aantal retry-pogingen en concurrency. Onbeperkte retry-loops kunnen alle workers bezighouden en herstel moeilijker maken dan het oorspronkelijke incident.

Houd een recovery-pad naar de source of truth

Sla voor kritieke jobs voldoende state op in de primaire database om werk na Redis-verlies opnieuw te kunnen opbouwen. Een queue moet de verwerking versnellen, niet het enige record worden dat een klantactie heeft plaatsgevonden.

Begin met een verifieerbare deployment

Provision Redis in een non-productionproject, test de cache-fallback en dubbele aflevering van jobs en leg het foutbeleid expliciet vast voordat je kritiek werk routeert.

Start gratis op app.dockup.ai. Het Free-plan kost $0 per maand, bevat $10 starttegoed en ondersteunt één workspace, drie databases en drie deployments.

FAQ

Kan Dockup managed Redis aanmaken?

Ja. Gebruik het create-commando voor managed databases met type redis en verbind de applicatie vervolgens met de geretourneerde connectiongegevens die als secret zijn opgeslagen.

Moeten cache- en queuedata dezelfde Redis-instantie delen?

Dat kan bij een kleine workload met een laag risico, maar scheiding is veiliger wanneer cache-eviction en kritieke queue-retentie verschillende eisen stellen aan beschikbaarheid en geheugen.

Garandeert Redis dat een job in de queue precies één keer wordt uitgevoerd?

Ga niet uit van een algemene exactly-once-garantie. De deliverysemantiek hangt af van de queue library en het workerontwerp. Maak side effects daarom idempotent.

Kan Redis Dockup private networking gebruiken?

Ja. Schakel het projectnetwerk in, redeploy de services die Redis gebruiken zodat ze interne variabelen ontvangen en maak de Redis-database desgewenst alleen privé toegankelijk.

Is een Redis-back-up voldoende voor een kritieke job queue?

Niet per se. Een back-up vertegenwoordigt een momentopname en bevat mogelijk geen nieuwer geaccepteerd werk. Houd herstelbare bronrecords bij en definieer recovery van jobs op applicatieniveau.