Redis-cache- og køarbeidslaster på Dockup

Arbeidslaster for Redis-cache og kø kan bruke den samme administrerte Redis-tjenesten, men de har ulike krav til korrekthet. En cache kan vanligvis bygges opp igjen etter datatap. En kø kan representere arbeid som ikke må forkastes i stillhet eller behandles to ganger.

Dockup klargjør Redis som en administrert database, tilbyr operasjoner for størrelse og logger, støtter arbeidsflyter for sikkerhetskopiering og flytting av noder, og kan koble databasen til applikasjonstjenester gjennom prosjektets private nettverk.

Hvordan klargjør du administrert Redis?

Opprett Redis i det valgte arbeidsområdet:

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

Bekreft databasemålet:

dockup db list --json

Lagre den returnerte tilkoblingsinformasjonen utenfor kildekontrollen, og koble den til tjenesten som bruker den, som en secret:

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

dockup deploy production/api --wait --json

Ved redeploy opprettes en ny applikasjonscontainer med det oppdaterte miljøet. En restart av den gamle containeren tar ikke i bruk en nylig lagret ønsket verdi.

Bruk separate Redis-databaser eller instanser når cache-eviction og kritisk oppbevaring av kødata ikke bør konkurrere om det samme minnet. Isolasjon gjør det også enklere å diagnostisere hendelser og styre tilgang.

Når bør Redis brukes som cache?

En cache reduserer gjentatt arbeid eller forsinkelse ved å lagre avledede data. Kilden til sannheten er fortsatt et annet sted, vanligvis PostgreSQL, MySQL, MongoDB, et eksternt API eller en deterministisk beregning.

Et godt cache-design definerer:

• Format og namespace for cache-nøkler.
• Time to live.
• Maksimalt akseptabel foreldelse.
• Utløser for invalidation.
• Atferd ved cache miss.
• Atferd når Redis ikke er tilgjengelig.
• Beskyttelse mot thundering herd.
• Hvilke data som aldri må caches.

Feil	Sikker cache-atferd
Nøkkel mangler	Beregn på nytt eller les fra kilden til sannheten
Redis er utilgjengelig	Gå over til kilden med rate-beskyttelse
Foreldet oppføring	La den utløpe eller invalider den
Endring i serialisering	Versjoner key-namespace
Minnepress	Evict data som kan bygges opp igjen, først
Hot key	Legg til lokal cache, sharding eller request coalescing

Ikke gjør hele applikasjonen utilgjengelig bare fordi en valgfri cache er nede. Bruk bounded timeouts og fallback-stier. På den annen side må du ikke skjule alle feil; et langvarig cache-avbrudd kan overbelaste kildedatabasen.

Hva endrer seg når Redis brukes som jobbkø?

En kø representerer ventende arbeid, så applikasjonen må definere semantikk for levering og gjenoppretting. Redis er i seg selv en datastrukturserver; garantiene avhenger av købiblioteket og worker-protokollen.

Ta stilling til:

1. Når regnes en jobb som godtatt?
2. Når sendes acknowledgment?
3. Hva skjer hvis en worker krasjer etter å ha utført sideeffekten, men før acknowledgment?
4. Hvordan forsinkes og begrenses retries?
5. Hvor havner jobber som feiler permanent?
6. Hvordan gjøres duplikatkjøring trygg?
7. Hvordan overvåkes kødybden?
8. Kan job payload rekonstrueres?

Bygg idempotente workers. En betalingsbelastning, e-post eller dataimport kan bli levert mer enn én gang etter en feil. Bruk en forretningsmessig idempotency key, og registrer fullføring i databasen som er kilden til sannheten.

Skill kønavn etter arbeidslast og prioritet. En treg mediejobb bør ikke sulte ut behandling av passordtilbakestillinger eller webhooks. Unngå å legge secrets i job payload når en referanse-ID er tilstrekkelig.

En Redis-cache- og kø-deploy bør dokumentere hvilke nøkler som kan slettes, og hvilke som representerer forretningskritisk arbeid.

Hvordan kobler privat nettverk tjenester til Redis?

Aktiver prosjektnettverk:

dockup network enable production --json

Redis-tjenesten blir tilgjengelig via det stabile vertsnavnet <slug>.internal fra tjenester i samme prosjekt. Redeploy applikasjonen slik at Dockup kan injisere de interne tilkoblingsvariablene.

For å gjøre Redis tilgjengelig bare privat:

dockup db private production/app-redis --json

Gjenopprett den offentlige lytteren ved behov:

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

Privat nettverk fjerner veien gjennom det offentlige internett for trafikk mellom tjenester i samme prosjekt, men erstatter ikke autentisering. Hold Redis-tilkoblingsinformasjonen hemmelig, og begrens hvilke tjenester som mottar den.

Ulike prosjekter kan ikke nå hverandres private nettverk. Denne grensen kan være nyttig når produksjon og staging ikke skal dele cache-nøkler eller køarbeid.

Se private nettverk og interne domener for hele modellen.

Hvordan bør Redis-feil påvirke applikasjonen?

Klassifiser arbeidslasten før du skriver recovery-kode.

Arbeidslast	Toleranse for tap	Respons ved avbrudd
HTML-fragmentcache	Høy	Bygg opp igjen fra kilden
Session store	Lav til middels	Kan logge brukere ut; utform en fallback
Rate-limit-tellere	Avhenger av policy	Velg eksplisitt fail open eller fail closed
Jobbkø	Lav	Slutt å ta imot arbeid eller lagre det et annet sted
Distribuert lock	Svært lav for kritiske seksjoner	Bruk fencing/idempotency
Feature-cache	Høy	Bruk standardverdi eller kilden

En cache-klient bør ikke retry for alltid. Lange retry-perioder kan bruke opp alle applikasjonsworkers og gjøre en Redis-hendelse til et fullstendig avbrudd. Køworkers bør trappe ned, eksponere mislykket arbeid og stoppe etter en definert policy.

Undersøk Redis-størrelsen og runtime-loggene til applikasjonen som bruker den:

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

Vekst i størrelse kan tyde på manglende utløp, ukontrollert kødybde, for store payloads eller forlatte namespaces. Ikke behandle en restart av databasen som første respons på timeouts i applikasjonen; sjekk konfigurasjon, nettverk og klientatferd først.

Hvordan henger backup, migrering og overvåking sammen med Redis?

Dockup eksponerer arbeidsflyten for backup av den administrerte databasen:

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

Om en Redis-backup oppfyller arbeidslastens recovery-mål, avhenger av hva dataene betyr. En cache-backup kan være unødvendig. En kø-backup kan likevel miste arbeid som ble godtatt etter tidspunktet for backupen. Forretningskritiske jobber bør ha en gjenopprettbar kildeoppføring utenfor køen når det er mulig.

Flytt Redis mellom noder med:

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

Planlegg hvilken påvirkning migreringen får på klienter og workers. Bekreft at reconnection-, retry- og idempotency-atferden fungerer før produksjonssetting.

Overvåk metrics på applikasjonsnivå i tillegg til databasestørrelsen:

• Cache hit ratio.
• Miss-latens.
• Evictions.
• Kødybde og alder på den eldste jobben.
• Antall vellykkede jobber, retries og feil.
• Worker-concurrency.
• Redis-tilkoblingsfeil.
• Payload-størrelse.

Dockup måler CPU-, RAM- og diskforbruk per minutt opp mot planens forbrukssaldo. Den anbefalte Pro-planen koster $20 per måned og inkluderer $20 i brukskreditt, men det er metrics fra arbeidslasten – ikke plannavnet – som bør styre kapasitetsvalgene.

Hva bør stå på en trygg Redis-sjekkliste for produksjon?

Før lansering må du kontrollere:

1. Nøyaktig project/db-mål.
2. Ansvarsområdene for cache og kø er dokumentert.
3. Connection URL er en maskert secret.
4. Policyen for privat nettverk er besluttet.
5. Alle cacher har TTL eller eksplisitt invalidation.
6. Køworkers er idempotente.
7. Retry- og dead-letter-atferd er definert av køsystemet.
8. Det finnes varsler for størrelse og kødybde.
9. Verdien og begrensningene ved backup er forstått.
10. Restart og migrering krever godkjenning.

Eksempel på separasjon av cache og kø

En liten applikasjon kan begynne med én Redis-database når risikoen er lav, men bruke tydelige key-prefixer:

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

Etter hvert som arbeidslasten vokser, bør du skille kritisk køtilstand fra cache-tilstand som evictes aggressivt. Dette er en operasjonell grense, ikke bare et spørsmål om navngiving.

Et vellykket Redis-cache- og kø-design gjør applikasjonens atferd forutsigbar når Redis er rask, treg, tom eller utilgjengelig.

Se administrert PostgreSQL for operasjoner der en relasjonell database er kilden til sannheten. Se strategier for databaseskalering for bredere kapasitetsvalg. Bruk Dockup CLI-referansen for oppdaterte databasekommandoer.

Definer utvikling av nøkler og payloads

Cache- og kødata lever lenger enn én enkelt applikasjonsprosess. En ny release kan lese nøkler som ble skrevet av den forrige releasen under en blue-green cutover. Versjoner key-namespaces og job payloads slik at begge versjonene kan eksistere samtidig.

For køer bør du ta med en payload-versjon og sørge for at workers kan behandle minst de versjonene som fortsatt kan ligge og vente. En rollback av en deployment kan gjenopprette gammel kode mens jobber i nytt format fortsatt ligger i Redis. Uten kompatibilitet kan en rollback av applikasjonen føre til flere feil.

Test ressursbelastning med hensikt

Test manglende nøkler, trege Redis-responser, tilkoblingsbrudd, købacklogg, duplikatlevering og en full eller nesten full minnetilstand i et miljø som ikke er produksjon. Følg med på om applikasjonen feiler åpent, feiler lukket, retrier eller overbelaster en annen avhengighet.

En Redis-cache- og kø-runbook bør sette grenser for antall retry-forsøk og concurrency. Ubegrensede retry-løkker kan bruke opp alle workers og gjøre gjenoppretting vanskeligere enn den opprinnelige hendelsen.

Behold en recovery-vei til kilden til sannheten

For kritiske jobber bør du lagre nok tilstand i primærdatabasen til å rekonstruere arbeidet etter tap av Redis. En kø bør fremskynde behandlingen, ikke bli den eneste registreringen av at en kundehandling har funnet sted.

Start med en deployment som kan verifiseres

Klargjør Redis i et prosjekt som ikke er produksjon, test cache-fallback og duplikatlevering av jobber, og gjør feilhåndteringspolicyen eksplisitt før du sender kritisk arbeid gjennom systemet.

Start gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett arbeidsområde, tre databaser og tre deployments.

Vanlige spørsmål

Kan Dockup opprette administrert Redis?

Ja. Bruk kommandoen for å opprette en administrert database med typen redis, og koble deretter applikasjonen til den returnerte tilkoblingsinformasjonen som er lagret som en secret.

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

Det kan fungere for en liten arbeidslast med lav risiko, men separasjon er tryggere når cache-eviction og kritisk oppbevaring av kødata har ulike krav til tilgjengelighet og minne.

Garanterer Redis at en jobb i køen kjøres nøyaktig én gang?

Nei, du bør ikke anta noen generell garanti for exactly-once. Leveringssemantikken avhenger av købiblioteket og worker-designet, så gjør sideeffekter idempotente.

Kan Redis bruke Dockups private nettverk?

Ja. Aktiver prosjektnettverket, redeploy tjenestene som bruker Redis for å få interne variabler, og gjør eventuelt Redis-databasen tilgjengelig bare privat.

Er en Redis-backup tilstrekkelig for en kritisk jobbkø?

Ikke nødvendigvis. Den representerer et bestemt tidspunkt og inkluderer kanskje ikke nyere arbeid som er godtatt. Behold gjenopprettbare kildeoppføringer, og definer recovery av jobber på applikasjonsnivå.