Redis cache a queue workloady na Dockup

Redis cache a queue workloady môžu využívať rovnakú managed Redis službu, no majú odlišné požiadavky na správnosť. Cache je zvyčajne možné po strate znova vytvoriť. Queue môže predstavovať prácu, ktorá sa nesmie potichu zahodiť ani spracovať dvakrát.

Dockup vytvára Redis ako managed databázu, poskytuje operácie na zistenie veľkosti a prácu s logmi, podporuje workflowy zálohovania a migrácie node a dokáže pripojiť databázu k aplikačným službám prostredníctvom privátnej siete projektu.

Ako vytvoriť managed Redis?

Vytvorte Redis vo vybranom workspace:

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

Overte cieľovú databázu:

dockup db list --json

Vrátené údaje na pripojenie uložte mimo source control a pripojte ich ku konzumentovi ako secret:

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

dockup deploy production/api --wait --json

Redeploy vytvorí nový aplikačný container s aktualizovaným prostredím. Reštart starého containeru neuplatní novú uloženú požadovanú hodnotu.

Samostatné Redis databázy alebo inštancie používajte vtedy, keď sa správanie eviction v cache a kritická retencia queue nemajú navzájom deliť o rovnakú pamäť. Izolácia tiež zjednodušuje diagnostiku incidentov a riadenie prístupu.

Kedy používať Redis ako cache?

Cache znižuje množstvo opakovanej práce alebo latenciu ukladaním odvodených dát. Source of truth zostáva inde, zvyčajne v PostgreSQL, MySQL, MongoDB, externej API alebo v deterministickom výpočte.

Dobrý návrh cache definuje:

• Formát cache key a namespace.
• Time to live.
• Maximálnu prijateľnú zastaranosť.
• Spúšťač invalidácie.
• Správanie pri cache miss.
• Správanie v prípade nedostupnosti Redis.
• Ochranu pred thundering herd.
• Ktoré dáta sa nikdy nesmú ukladať do cache.

Zlyhanie	Bezpečné správanie cache
Chýbajúci key	Znova vypočítať alebo načítať zo source of truth
Redis je nedostupný	Prejsť na source s rate protection
Zastaraný záznam	Nechať expirovať alebo invalidovať
Zmena serializácie	Verzionovať key namespace
Tlak na pamäť	Najskôr evictovať dáta, ktoré možno znova vytvoriť
Hot key	Pridať lokálnu cache, sharding alebo request coalescing

Celú aplikáciu neznefunkčňujte iba preto, že je voliteľná cache nedostupná. Používajte ohraničené timeouty a fallback cesty. Na druhej strane neskrývajte všetky zlyhania; dlhodobý výpadok cache môže preťažiť zdrojovú databázu.

Čo sa zmení, keď sa Redis používa ako job queue?

Queue predstavuje čakajúcu prácu, preto musí aplikácia definovať sémantiku doručenia a obnovy. Redis je samotný server dátových štruktúr; záruky závisia od queue knižnice a protokolu workera.

Rozhodnite:

1. Kedy sa job považuje za prijatý?
2. Kedy sa potvrdí?
3. Čo sa stane, ak worker spadne po vykonaní side effectu, ale pred potvrdením?
4. Ako sa odkladajú a obmedzujú retry?
5. Kam sa presunú trvalo neúspešné joby?
6. Ako sa zabezpečí bezpečné opakované vykonanie?
7. Ako sa sleduje hĺbka queue?
8. Je možné payload jobu zrekonštruovať?

Vytvárajte idempotentných workerov. Platba, e-mail alebo import dát môže byť po zlyhaní doručený viackrát. Použite business idempotency key a zaznamenajte dokončenie v databáze, ktorá je source of truth.

Queue names oddeľujte podľa workloadu a priority. Pomalý media job by nemal blokovať spracovanie resetovania hesla alebo webhookov. Do payloadov jobov nevkladajte secrets, ak postačuje referenčné ID.

Nasadenie Redis cache a queue by malo dokumentovať, ktoré keys sú zahoditeľné a ktoré predstavujú business prácu.

Ako privátna sieť pripája služby k Redis?

Povoľte sieť projektu:

dockup network enable production --json

Redis služba bude zo služieb v rovnakom projekte dostupná cez stabilný hostname <slug>.internal. Aplikáciu redeploynite, aby do nej Dockup mohol vložiť interné connection variables.

Ak má byť Redis dostupný iba privátne:

dockup db private production/app-redis --json

V prípade potreby obnovte verejný listener:

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

Privátna sieť odstraňuje verejnú internetovú cestu pre komunikáciu v rámci rovnakého projektu, nenahrádza však autentifikáciu. Údaje na pripojenie k Redis uchovávajte ako secret a obmedzte, ktoré služby k nim získajú prístup.

Odlišné projekty nemôžu pristupovať do navzájom privátnych sietí. Táto hranica môže byť užitočná, keď production a staging nesmú zdieľať cache keys ani queue prácu.

Úplný model nájdete v článku privátna sieť a interné domény.

Ako majú zlyhania Redis ovplyvniť aplikáciu?

Pred napísaním recovery kódu klasifikujte workload.

Workload	Tolerancia straty	Reakcia na výpadok
HTML fragment cache	Vysoká	Znova vytvoriť zo zdroja
Session store	Nízka až stredná	Používatelia môžu byť odhlásení; navrhnite fallback
Rate-limit counters	Závisí od policy	Explicitne zvoliť fail open alebo fail closed
Job queue	Nízka	Prestať prijímať alebo uložiť inde
Distributed lock	Veľmi nízka v kritických sekciách	Použiť fencing/idempotency
Feature cache	Vysoká	Použiť predvolenú hodnotu alebo source

Klient cache by nemal retryovať donekonečna. Dlhé retry môžu spotrebovať všetkých aplikačných workerov a zmeniť incident Redis na úplný výpadok. Queue workery by mali používať backoff, sprístupniť neúspešnú prácu a zastaviť sa po definovanej policy.

Skontrolujte veľkosť Redis a runtime logy konzumentskej aplikácie:

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

Rast veľkosti môže signalizovať chýbajúcu expiráciu, nekontrolovaný rast queue, príliš veľké payloady alebo opustené namespaces. Reštart databázy nepovažujte za prvú reakciu na timeouty aplikácie; najprv skontrolujte konfiguráciu, sieť a správanie klienta.

Ako spolu súvisia backup, migrácia a monitoring Redis?

Dockup poskytuje workflow zálohovania managed databázy:

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

To, či backup Redis spĺňa recovery cieľ workloadu, závisí od významu dát. Backup cache môže byť zbytočný. Backup queue môže aj tak stratiť prácu prijatú po vytvorení zálohy. Business-kritické joby by mali mať podľa možnosti obnoviteľný source record mimo queue.

Redis môžete presunúť medzi nodmi pomocou:

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

Naplánujte vplyv migrácie na klientov a workerov. Pred nasadením do production overte, že funguje reconnection, retry aj idempotency.

Okrem veľkosti databázy monitorujte aj metriky na úrovni aplikácie:

• Cache hit ratio.
• Latencia pri cache miss.
• Evictions.
• Hĺbka queue a vek najstaršieho jobu.
• Počty úspešných jobov, retry a zlyhaní.
• Concurrency workerov.
• Chyby pripojenia k Redis.
• Veľkosť payloadov.

Dockup meria spotrebu CPU, RAM a disku každú minútu voči balance plánu. Odporúčaný Pro plán stojí $20 mesačne a zahŕňa kredit na využitie vo výške $20, no o kapacite by mali rozhodovať metriky workloadu, nie názov plánu.

Aký je bezpečný production checklist pre Redis?

Pred spustením overte:

1. Presný cieľ project/db.
2. Sú zdokumentované zodpovednosti cache a queue.
3. URL na pripojenie je masked secret.
4. Je rozhodnutá policy privátnej siete.
5. Každá cache má TTL alebo explicitnú invalidáciu.
6. Queue workery sú idempotentné.
7. Retry a dead-letter správanie definuje queue systém.
8. Existujú alerty na veľkosť a hĺbku queue.
9. Hodnota a obmedzenia backupu sú známe.
10. Reštart a migrácia vyžadujú schválenie.

Príklad oddelenia cache a queue

Malá aplikácia môže začať s jednou Redis databázou, ak je riziko nízke, no používajte jasné prefixy keys:

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

S rastom workloadu oddeľte kritický stav queue od stavu cache, ktorý sa agresívne evictuje. Ide o operačnú hranicu, nielen o preferenciu pomenovania.

Úspešný návrh Redis cache a queue robí správanie aplikácie predvídateľným vtedy, keď je Redis rýchly, pomalý, prázdny alebo nedostupný.

Operácie so source of truth v relačnej databáze nájdete v článku managed PostgreSQL. Širšie možnosti kapacity nájdete v článku stratégie škálovania databáz. Aktuálne databázové príkazy nájdete v referencii Dockup CLI.

Definujte evolúciu keys a payloadov

Dáta v cache a queue prežívajú jeden aplikačný proces. Nové release môže počas blue-green cutoveru čítať keys, ktoré zapísalo predchádzajúce release. Verzionujte namespaces keys a payloady jobov, aby mohli obe verzie fungovať súčasne.

V prípade queue zahrňte do payloadu jeho verziu a zabezpečte, aby workery dokázali spracovať aspoň tie verzie, ktoré ešte môžu čakať. Rollback deploymentu môže obnoviť starý kód, zatiaľ čo joby v novom formáte zostanú v Redis. Bez kompatibility môže rollback aplikácie zvýšiť počet zlyhaní.

Záťaž zdrojov testujte zámerne

V non-production prostredí testujte chýbajúce keys, pomalé odpovede Redis, resetovanie pripojení, backlog queue, duplicitné doručenie a stav úplne alebo takmer zaplnenej pamäte. Sledujte, či aplikácia použije fail open, fail closed, retry alebo preťaží inú dependency.

Runbook pre Redis cache a queue by mal stanoviť limity počtu retry a concurrency. Neobmedzené retry slučky môžu spotrebovať všetkých workerov a sťažiť obnovu viac než pôvodný incident.

Zachovajte recovery cestu k source of truth

Pri kritických joboch uložte do primárnej databázy dostatok stavu na zrekonštruovanie práce po strate Redis. Queue má urýchľovať spracovanie, nie byť jediným záznamom o tom, že sa uskutočnila akcia zákazníka.

Začnite s overiteľným nasadením

Vytvorte Redis v non-production projekte, otestujte fallback cache a duplicitné doručenie jobov a ešte pred smerovaním kritickej práce explicitne definujte policy pri zlyhaní.

Začnite bezplatne na app.dockup.ai. Free plán stojí $0 mesačne, zahŕňa počiatočný kredit $10 a podporuje jeden workspace, tri databázy a tri deploymenty.

FAQ

Dokáže Dockup vytvoriť managed Redis?

Áno. Použite príkaz na vytvorenie managed databázy s typom redis a potom pripojte aplikáciu pomocou vrátených údajov na pripojenie uložených ako secret.

Mali by cache a queue dáta zdieľať jednu Redis inštanciu?

Pri malom workloadu s nízkym rizikom môžu, no oddelenie je bezpečnejšie, keď majú eviction cache a kritická retencia queue odlišné požiadavky na dostupnosť a pamäť.

Zaručuje Redis, že sa queued job vykoná presne raz?

Nie. Nemožno predpokladať všeobecnú záruku exact-once. Sémantika doručenia závisí od queue knižnice a návrhu workera, preto side effects navrhujte ako idempotentné.

Môže Redis používať privátnu sieť Dockup?

Áno. Povoľte sieť projektu, redeploynite konzumentské služby kvôli interným premenným a podľa potreby nastavte Redis databázu ako dostupnú iba privátne.

Stačí backup Redis pre kritickú job queue?

Nie nevyhnutne. Predstavuje stav v konkrétnom čase a nemusí obsahovať novšiu prijatú prácu. Uchovávajte obnoviteľné source records a definujte recovery jobov na úrovni aplikácie.