Úlohy pro Redis cache a fronty na Dockup

Úlohy typu Redis cache a fronta mohou využívat stejnou spravovanou službu Redis, ale mají odlišné požadavky na správnost. Cache lze po ztrátě obvykle znovu vytvořit. Fronta může představovat práci, která nesmí být bez upozornění zahozena ani zpracována dvakrát.

Dockup zřizuje Redis jako spravovanou databázi, poskytuje informace o velikosti a logy, podporuje workflow zálohování a migrace uzlů a dokáže databázi připojit k aplikačním službám prostřednictvím privátní sítě projektu.

Jak zřídit spravovaný Redis?

Vytvořte Redis ve vybraném workspace:

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

Ověřte cíl databáze:

dockup db list --json

Vrácené údaje pro připojení uložte mimo zdrojový kód a připojte je ke službě, která je využívá, jako secret:

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

dockup deploy production/api --wait --json

Nové nasazení vytvoří nový aplikační kontejner s aktualizovaným prostředím. Restart starého kontejneru nově uloženou požadovanou hodnotu neaplikuje.

Samostatné Redis databáze nebo instance používejte v situacích, kdy by se chování eviction cache a kritická retence fronty neměly přetahovat o stejnou paměť. Izolace také zjednodušuje diagnostiku incidentů a řízení přístupu.

Kdy používat Redis jako cache?

Cache omezuje opakovanou práci nebo latenci ukládáním odvozených dat. Zdroj pravdy zůstává jinde, obvykle v PostgreSQL, MySQL, MongoDB, externím API nebo v deterministickém výpočtu.

Dobře navržená cache definuje:

• Formát klíče cache a namespace.
• Time to live.
• Maximální přijatelnou zastaralost.
• Spouštěč invalidace.
• Chování při cache miss.
• Chování v případě nedostupnosti Redis.
• Ochranu proti thundering herd.
• Která data se nikdy nesmějí ukládat do cache.

Selhání	Bezpečné chování cache
Chybějící klíč	Znovu vypočítat nebo načíst ze zdroje pravdy
Redis není dostupný	Přepnout na zdroj s ochranou proti přetížení
Zastaralá položka	Nechat ji expirovat nebo ji zneplatnit
Změna serializace	Verzionovat namespace klíčů
Tlak na paměť	Nejprve vyřadit data, která lze znovu vytvořit
Hot key	Přidat lokální cache, sharding nebo slučování požadavků

Neznefunkčňujte celou aplikaci jen proto, že nefunguje volitelná cache. Používejte omezené timeouty a fallback cesty. Na druhou stranu neskrývejte všechna selhání; dlouhodobý výpadek cache může přetížit zdrojovou databázi.

Co se změní, když Redis používáte jako job queue?

Fronta představuje čekající práci, takže aplikace musí definovat sémantiku doručení a obnovy. Redis je sám o sobě server datových struktur; záruky závisí na knihovně fronty a protokolu workeru.

Rozhodněte:

1. Kdy je úloha považována za přijatou?
2. Kdy je potvrzena?
3. Co se stane, když worker spadne po provedení vedlejšího efektu, ale před potvrzením?
4. Jak se zpožďují a omezují opakované pokusy?
5. Kam se přesouvají trvale neúspěšné úlohy?
6. Jak zajistit bezpečnost duplicitního zpracování?
7. Jak sledovat délku fronty?
8. Lze payload úlohy znovu sestavit?

Workery navrhujte jako idempotentní. Platba, e-mail nebo import dat mohou být po selhání doručeny více než jednou. Použijte business idempotency key a zaznamenejte dokončení ve zdrojové databázi pravdy.

Názvy front oddělujte podle typu úlohy a priority. Pomalá úloha zpracování médií by neměla blokovat resetování hesel nebo zpracování webhooků. Pokud stačí referenční ID, nevkládejte do payloadů úloh secrety.

Nasazení typu Redis cache a fronta by mělo dokumentovat, které klíče lze zahodit a které představují obchodní práci.

Jak privátní síť propojí služby s Redis?

Povolte síťování projektu:

dockup network enable production --json

Služba Redis bude ze služeb ve stejném projektu dostupná prostřednictvím stabilního hostname <slug>.internal. Aplikaci znovu nasaďte, aby Dockup mohl vložit interní proměnné připojení.

Chcete-li Redis zpřístupnit pouze privátně:

dockup db private production/app-redis --json

Veřejný listener znovu povolíte v případě potřeby:

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

Privátní síťování odstraňuje pro provoz v rámci stejného projektu cestu přes veřejný internet, nenahrazuje však autentizaci. Údaje pro připojení k Redis uchovávejte jako secret a omezte, které služby je obdrží.

Různé projekty nemohou přistupovat do privátní sítě toho druhého. Tato hranice může být užitečná, když produkce a staging nesmějí sdílet klíče cache ani práci ve frontách.

Úplný model najdete v článku privátní síťování a interní domény.

Jak mají selhání Redis ovlivnit aplikaci?

Než napíšete recovery kód, klasifikujte typ úlohy.

Úloha	Tolerance ztráty	Reakce na výpadek
Cache HTML fragmentů	Vysoká	Znovu sestavit ze zdroje
Úložiště session	Nízká až střední	Uživatelé mohou být odhlášeni; navrhněte fallback
Počítadla rate limitu	Závisí na pravidlech	Explicitně zvolit fail open nebo fail closed
Fronta úloh	Nízká	Přestat přijímat nové úlohy nebo je ukládat jinam
Distribuovaný lock	Velmi nízká u kritických sekcí	Použít fencing/idempotenci
Cache feature flags	Vysoká	Použít výchozí hodnotu nebo zdroj

Klient cache by neměl opakovat pokusy donekonečna. Dlouhé retry mohou spotřebovat všechny aplikační workery a změnit incident Redis v úplný výpadek. Workery fronty by měly používat backoff, zpřístupnit neúspěšnou práci a po definovaném počtu pokusů se zastavit.

Zkontrolujte velikost Redis a runtime logy aplikace, která jej využívá:

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

Růst velikosti může signalizovat chybějící expiraci, nekontrolovaný růst fronty, příliš velké payloady nebo opuštěné namespace. Restart databáze nepovažujte za první reakci na timeouty aplikace; nejprve zkontrolujte konfiguraci, síťování a chování klienta.

Jak do Redis zapadají zálohy, migrace a monitoring?

Dockup zpřístupňuje workflow zálohování spravované databáze:

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

To, zda záloha Redis splňuje cíl obnovy dané úlohy, závisí na významu uložených dat. Záloha cache může být zbytečná. Záloha fronty může přesto znamenat ztrátu práce přijaté po okamžiku zálohy. Kritické obchodní úlohy by pokud možno měly mít obnovitelný zdrojový záznam mimo frontu.

Redis mezi uzly přesunete pomocí:

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

Naplánujte dopad migrace na klienty a workery. Před nasazením do produkce ověřte, že funguje opětovné připojení, retry i idempotence.

Kromě velikosti databáze sledujte také metriky na úrovni aplikace:

• Poměr cache hitů.
• Latence cache miss.
• Evictions.
• Délka fronty a stáří nejstarší úlohy.
• Počty úspěšných, opakovaných a neúspěšných úloh.
• Souběžnost workerů.
• Chyby připojení k Redis.
• Velikost payloadů.

Dockup měří spotřebu CPU, RAM a disku každou minutu v porovnání s limity plánu. Doporučený Pro plan stojí 20 $ měsíčně a zahrnuje kredit na využití ve výši 20 $, ale o kapacitě by měly rozhodovat metriky úloh, nikoli název plánu.

Jak vypadá bezpečný produkční checklist pro Redis?

Před spuštěním ověřte:

1. Přesný cíl project/db.
2. Jsou zdokumentovány odpovědnosti cache a fronty.
3. URL pro připojení je maskovaný secret.
4. Je rozhodnuto o pravidlech privátního síťování.
5. Každá cache má TTL nebo explicitní invalidaci.
6. Workery fronty jsou idempotentní.
7. Retry a dead-letter chování definuje systém fronty.
8. Existují alerty na velikost a délku fronty.
9. Jsou známé přínosy a omezení zálohování.
10. Restart a migrace vyžadují schválení.

Příklad oddělení cache a fronty

Malá aplikace může začít s jednou Redis databází, pokud je riziko nízké, ale používejte jasné prefixy klíčů:

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

S růstem úloh oddělte kritický stav fronty od stavu cache, který se agresivně vyřazuje. Jde o provozní hranici, nikoli pouze o preferenci pojmenování.

Úspěšný návrh Redis cache a fronty zajišťuje předvídatelné chování aplikace ve chvíli, kdy je Redis rychlý, pomalý, prázdný nebo nedostupný.

Operace se zdrojem pravdy v relační databázi najdete v článku spravovaný PostgreSQL. Širší možnosti kapacity popisuje článek strategie škálování databází. Aktuální databázové příkazy najdete v referenci Dockup CLI.

Definujte vývoj klíčů a payloadů

Data v cache a frontách přežívají jediný aplikační proces. Nová verze může během blue-green cutoveru číst klíče zapsané předchozí verzí. Namespace klíčů a payloady úloh verzujte, aby obě verze mohly dočasně koexistovat.

U front zahrňte do payloadu jeho verzi a zajistěte, aby workery dokázaly zpracovat alespoň verze, které ještě mohou čekat. Rollback nasazení může obnovit starý kód, zatímco úlohy v novém formátu zůstanou v Redis. Bez kompatibility může rollback aplikace zvýšit počet selhání.

Tlak na zdroje testujte záměrně

V neprodukčním prostředí testujte chybějící klíče, pomalé odpovědi Redis, resetování připojení, nahromadění úloh ve frontě, duplicitní doručení a stav plné nebo téměř plné paměti. Sledujte, zda aplikace použije fail open, fail closed, retry nebo přetíží jinou závislost.

Runbook pro Redis cache a frontu by měl stanovit limity počtu retry a souběžnosti. Neomezené retry smyčky mohou spotřebovat všechny workery a ztížit obnovu více než původní incident.

Zachovejte cestu k obnovení ze zdroje pravdy

U kritických úloh uložte do primární databáze dostatek stavu k opětovnému sestavení práce po ztrátě Redis. Fronta má zrychlovat zpracování, nikoli se stát jediným záznamem o tom, že došlo k akci zákazníka.

Začněte s ověřitelným nasazením

Zřiďte Redis v neprodukčním projektu, otestujte fallback cache a duplicitní doručování úloh a před směrováním kritické práce explicitně definujte pravidla chování při selhání.

Začněte zdarma na app.dockup.ai. Free plan stojí 0 $ měsíčně, zahrnuje počáteční kredit 10 $ a podporuje jeden workspace, tři databáze a tři nasazení.

FAQ

Dokáže Dockup vytvořit spravovaný Redis?

Ano. Použijte příkaz pro vytvoření spravované databáze s typem redis a poté aplikaci připojte pomocí vrácených údajů pro připojení uložených jako secret.

Měla by cache a data fronty sdílet jednu Redis instanci?

U malé úlohy s nízkým rizikem mohou, ale oddělení je bezpečnější v případě, že eviction cache a kritická retence fronty mají odlišné požadavky na dostupnost a paměť.

Zaručuje Redis, že se úloha ve frontě spustí právě jednou?

Nelze předpokládat obecnou záruku exactly-once. Sémantika doručení závisí na knihovně fronty a návrhu workeru, proto navrhujte vedlejší efekty jako idempotentní.

Lze Redis používat s privátní sítí Dockup?

Ano. Povolte síť projektu, znovu nasaďte služby, které Redis využívají, aby obdržely interní proměnné, a případně nastavte databázi Redis pouze jako privátní.

Stačí záloha Redis pro kritickou frontu úloh?

Ne nutně. Představuje stav k určitému okamžiku a nemusí zahrnovat novější přijatou práci. Uchovávejte obnovitelné zdrojové záznamy a definujte obnovu úloh na úrovni aplikace.