Redis-cache och köer på Dockup

Arbetsbelastningar med Redis-cache och köer kan använda samma hanterade Redis-tjänst, men har olika krav på korrekthet. En cache kan vanligtvis byggas om efter en förlust. En kö kan däremot representera arbete som inte får kasseras obemärkt eller bearbetas två gånger.

Dockup provisionerar Redis som en hanterad databas, tillhandahåller storleks- och loggoperationer, stöder arbetsflöden för säkerhetskopiering och nodmigrering och kan ansluta databasen till applikationstjänster via privat nätverk inom projektet.

Hur provisionerar man hanterad Redis?

Skapa Redis i den valda workspacen:

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

Bekräfta databasmålet:

dockup db list --json

Lagra det returnerade anslutningsmaterialet utanför source control och koppla det till den konsumerande tjänsten som en secret:

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

dockup deploy production/api --wait --json

En ny deployment skapar en ny applikationscontainer med den uppdaterade miljön. En omstart av den gamla containern tillämpar inte ett nyligen lagrat önskat värde.

Använd separata Redis-databaser eller instanser när cache-eviction och kritisk retention för köer inte bör konkurrera om samma minne. Isolering förenklar också incidentdiagnostik och åtkomstkontroll.

När bör Redis användas som cache?

En cache minskar upprepat arbete eller latency genom att lagra härledda data. Källan till sanningen finns fortfarande någon annanstans, vanligtvis PostgreSQL, MySQL, MongoDB, ett externt API eller en deterministisk beräkning.

En välgrundad cache-design definierar:

• Format och namespace för cache-nycklar.
• Time to live.
• Högsta acceptabla grad av inaktualitet.
• Invalideringstrigger.
• Beteende vid cache miss.
• Beteende när Redis inte är tillgängligt.
• Skydd mot thundering herd.
• Vilka data som aldrig får cachas.

Fel	Säkert cache-beteende
Nyckel saknas	Beräkna om eller läs från källan till sanningen
Redis är inte tillgängligt	Falla tillbaka till källan med rate protection
Föråldrad post	Låt den löpa ut eller invalidera den
Ändrad serialisering	Versionsindela nycklarnas namespace
Minnestryck	Evicta data som kan byggas om först
Hot key	Lägg till lokal cache, sharding eller request coalescing

Gör inte hela applikationen otillgänglig enbart för att en valfri cache ligger nere. Använd begränsade timeouts och fallback-vägar. Dölj samtidigt inte alla fel; ett långvarigt cache-avbrott kan överbelasta källdatabasen.

Vad förändras när Redis används som job queue?

En kö representerar väntande arbete, så applikationen måste definiera semantiken för leverans och återställning. Redis är i sig en datastruktursserver; garantierna beror på köbiblioteket och worker-protokollet.

Bestäm:

1. När anses ett jobb vara accepterat?
2. När kvitteras det?
3. Vad händer om en worker kraschar efter att side effect har utförts men före kvitteringen?
4. Hur fördröjs och begränsas retries?
5. Vart hamnar jobb som misslyckats permanent?
6. Hur görs duplicerad körning säker?
7. Hur observeras ködjupet?
8. Kan job payload återskapas?

Bygg idempotenta workers. En betalningsreservation, ett e-postmeddelande eller en dataimport kan levereras mer än en gång efter ett fel. Använd en business-idempotency key och registrera slutförandet i källan-till-sanning-databasen.

Separera könamn efter arbetsbelastning och prioritet. Ett långsamt mediejobb ska inte svälta ut behandling av lösenordsåterställningar eller webhooks. Undvik att placera secrets i job payloads när ett referens-ID räcker.

En Redis-cache- och ködeployment bör dokumentera vilka nycklar som kan kasseras och vilka som representerar affärsarbete.

Hur ansluter privat nätverk tjänster till Redis?

Aktivera projektnätverk:

dockup network enable production --json

Redis-tjänsten blir nåbar via sitt stabila <slug>.internal-värdnamn från tjänster i samma projekt. Gör en ny deployment av applikationen så att Dockup kan injicera de interna anslutningsvariablerna.

Gör Redis enbart privat:

dockup db private production/app-redis --json

Återställ den publika lyssnaren när det behövs:

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

Privat nätverk tar bort vägen via det publika internet för trafik inom samma projekt, men ersätter inte autentisering. Håll Redis-anslutningsmaterialet hemligt och begränsa vilka tjänster som får det.

Olika projekt kan inte nå varandras privata nätverk. Denna gräns kan vara användbar när production och staging inte får dela cache-nycklar eller köarbete.

Se privat nätverk och interna domäner för hela modellen.

Hur bör Redis-fel påverka applikationen?

Klassificera arbetsbelastningen innan du skriver recovery-kod.

Arbetsbelastning	Tolerans för förlust	Åtgärd vid avbrott
HTML-fragmentcache	Hög	Bygg om från källan
Session store	Låg till medel	Kan logga ut användare; utforma en fallback
Rate-limit-räknare	Beror på policy	Fail open eller fail closed uttryckligen
Job queue	Låg	Sluta acceptera jobb eller spara dem någon annanstans
Distributed lock	Mycket låg för kritiska sektioner	Använd fencing/idempotency
Feature cache	Hög	Använd standardvärde eller källan

En cache-klient bör inte retry:a för alltid. Långa retries kan förbruka alla application workers och förvandla en Redis-incident till ett fullständigt avbrott. Queue workers bör backa, exponera misslyckat arbete och stoppa enligt en definierad policy.

Inspektera Redis-storleken och runtime-loggarna för den konsumerande applikationen:

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

Ökad storlek kan tyda på att expiration saknas, att ködjupet skenar, att payloads är för stora eller att namespaces har övergetts. Behandla inte en omstart av databasen som den första åtgärden vid timeouts i applikationen; kontrollera först konfiguration, nätverk och klientbeteende.

Hur passar backup, migrering och övervakning ihop med Redis?

Dockup exponerar arbetsflödet för backup av den hanterade databasen:

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

Om en Redis-backup uppfyller arbetsbelastningens recovery-mål beror på vad datan betyder. En cache-backup kan vara onödig. En kö-backup kan fortfarande förlora arbete som accepterats efter backupens tidpunkt. Affärskritiska jobb bör om möjligt ha en återställningsbar källpost utanför kön.

Flytta Redis mellan noder med:

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

Planera hur migreringen påverkar klienter och workers. Bekräfta att återanslutning, retry och idempotency fungerar innan production.

Övervaka metrics på applikationsnivå utöver databasens storlek:

• Cache hit ratio.
• Miss latency.
• Evictions.
• Ködjup och ålder på det äldsta jobbet.
• Antal lyckade jobb, retries och fel.
• Worker concurrency.
• Redis-anslutningsfel.
• Payload-storlek.

Dockup mäter CPU-, RAM- och diskanvändning per minut mot planens saldo. Den rekommenderade Pro-planen kostar $20 per månad och inkluderar $20 i användningskredit, men det är arbetsbelastningens metrics – inte planens namn – som bör styra kapacitetsbesluten.

Vad ingår i en säker Redis-checklista för production?

Kontrollera före lansering:

1. Exakt project/db-mål.
2. Cache- och köansvar är dokumenterade.
3. Connection URL är en maskerad secret.
4. Policyn för privat nätverk är beslutad.
5. Varje cache har TTL eller explicit invalidering.
6. Queue workers är idempotenta.
7. Retry- och dead-letter-beteende definieras av kö-systemet.
8. Det finns larm för storlek och ködjup.
9. Backupens värde och begränsningar är kända.
10. Omstart och migrering kräver godkännande.

Exempel på separering av cache och kö

En liten applikation kan börja med en Redis-databas när risken är låg, men använda tydliga key prefixes:

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

När arbetsbelastningen växer bör du separera kritiskt kö-tillstånd från cache-tillstånd som evictas aggressivt. Detta är en operationell gräns, inte bara en fråga om namngivning.

En lyckad Redis-cache- och ködesign gör applikationens beteende förutsägbart när Redis är snabb, långsam, tom eller otillgänglig.

För operationer mot den relationella källan till sanningen, se hanterad PostgreSQL. För bredare kapacitetsval, se strategier för databasskalning. Använd Dockup CLI-referensen för aktuella databaskommandon.

Definiera hur nycklar och payloads utvecklas

Cache- och ködata lever längre än en enskild applikationsprocess. En ny release kan läsa nycklar som skrevs av den föregående releasen under en blue-green cutover. Versionsindela key namespaces och job payloads så att båda versionerna kan samexistera.

För köer ska du inkludera en payload-version och se till att workers kan behandla åtminstone de versioner som fortfarande kan ligga och vänta. En rollback av en deployment kan återställa gammal kod medan jobb i det nya formatet finns kvar i Redis. Utan kompatibilitet kan en rollback av applikationen öka antalet fel.

Testa resursbelastning avsiktligt

Testa i en icke-produktionsmiljö saknade nycklar, långsamma Redis-svar, återställda anslutningar, köbacklog, duplicerad leverans samt fullt eller nästan fullt minne. Observera om applikationen fail open, fail closed, retry:ar eller överbelastar ett annat beroende.

En Redis-cache- och kö-runbook bör sätta gränser för retry-försök och concurrency. Obegränsade retry-loopar kan förbruka alla workers och göra återställningen svårare än den ursprungliga incidenten.

Behåll en recovery-väg till källan

För kritiska jobb ska du lagra tillräckligt med tillstånd i den primära databasen för att kunna återskapa arbetet efter en Redis-förlust. En kö bör påskynda behandlingen, inte bli den enda registreringen av att en kundåtgärd har inträffat.

Börja med en verifierbar deployment

Provisionera Redis i ett icke-produktionsprojekt, testa cache-fallback och duplicerad jobbleverans och gör felpolicyn explicit innan du styr kritiskt arbete till systemet.

Börja gratis på app.dockup.ai. Free-planen kostar $0 per månad, inkluderar $10 i startkredit och stöder en workspace, tre databaser och tre deployments.

Vanliga frågor

Kan Dockup skapa hanterad Redis?

Ja. Använd kommandot för att skapa en hanterad databas med typen redis och anslut sedan applikationen med det returnerade anslutningsmaterialet, lagrat som en secret.

Bör cache- och ködata dela samma Redis-instans?

Det går bra för en liten arbetsbelastning med låg risk, men separering är säkrare när cache-eviction och kritisk retention för köer har olika krav på tillgänglighet och minne.

Garanterar Redis att ett köat jobb körs exakt en gång?

Nej, du bör inte utgå från någon generell garanti om exakt en körning. Leveranssemantiken beror på köbiblioteket och worker-designen, så gör side effects idempotenta.

Kan Redis använda Dockups privata nätverk?

Ja. Aktivera projektnätverket, gör en ny deployment av de konsumerande tjänsterna så att de interna variablerna injiceras och gör eventuellt Redis-databasen enbart privat.

Räcker en Redis-backup för en kritisk job queue?

Inte nödvändigtvis. Den representerar en tidpunkt och kanske inte innehåller nyare accepterat arbete. Behåll återställningsbara källposter och definiera recovery av jobb på applikationsnivå.