Slovník pojmů

Redis: rychlá data v paměti pro práci aplikace

Cache, relace, čítače a koordinace mohou být rychlé — jen pokud systém umí pracovat s expirací, výpadkem a neplatnými daty.

Stručná definice

Rychlé úložiště pro dočasný i provozní stav.

Redis nepracuje hlavně s tabulkami a SQL. Ukládá hodnoty pod klíči a nad nimi provádí operace nad řetězci, hash mapami, seznamy, množinami, seřazenými množinami a dalšími strukturami. Mnohé základní operace nad jedním klíčem jsou atomické, což je užitečné například pro čítač požadavků.

Data jsou primárně v RAM. Redis umí perzistenci na disk, replikaci i další provozní režimy, ale to nemění potřebu určit zdroj pravdy. Pro objednávky a nenahraditelné záznamy je jím obvykle relační databáze; Redis drží odvozenou, krátkodobou nebo koordinující vrstvu.

Použití

Kde rychlá data pomáhají

Use case má vycházet z toho, zda lze data dopočítat, jak dlouho platí a co se stane při výpadku.

cache produktů, konfigurace a náročných dotazů
session storage pro více instancí aplikace
čítače, kvóty a rate limiting API
krátkodobé tokeny a výsledky probíhající operace
fronty a streamy se zpracováním po skupinách
koordinace a distribuované zámky mezi workery

Praktický příklad

Cache produktového katalogu

E-shop hledá produkt v klíči product:4821:detail. Při cache miss ho načte z relační databáze, uloží serializovaný výsledek s krátkým TTL a odpověď vrátí návštěvníkovi.

Při změně ceny nebo skladu aplikace cache cíleně invaliduje či zapíše nový obsah. TTL je pojistka, ne mechanismus konzistence: bez invalidace mohou uživatelé do expirace vidět starý stav. Při výpadku Redisu aplikace čte zdroj pravdy, i když za cenu vyšší zátěže databáze.

Jak funguje

Cache-aside: klíč, TTL a fallback

Nejběžnější použití cache ukazuje, kde začíná odpovědnost aplikace.

Požadavek Backend potřebuje produkt nebo jiný krátkodobě platný stav.
Čtení klíče Přečte předvídatelně pojmenovaný klíč v Redisu.
Fallback Při cache miss nebo výpadku načte autoritativní databázi či službu.
Zápis s TTL Výsledek uloží na omezenou dobu, po níž klíč expiruje.
Invalidace Změna zdroje pravdy odpovídající klíče vymaže či obnoví a tým sleduje provozní metriky.

Důležité vlastnosti

Datové struktury, expirace a sdílený stav

Strukturu je vhodné volit podle operace, kterou aplikace potřebuje provést.

Datové struktury

String se hodí pro jednoduchou hodnotu či čítač, hash pro více vlastností, set pro unikátní členy, sorted set pro pořadí a stream pro záznamy zpracovávané skupinou.

TTL a cache

Po vypršení TTL Redis klíč při čtení považuje za expirovaný a průběžně jej odstraňuje. TTL sedí na cache, kvótu nebo jednorázový token, ne na jedinou kopii důležitých dat. Cache-aside stále vyžaduje invalidaci po zápisu.

Sessions a rate limiting

Sdílené relace usnadní běh více PHP instancí. Atomické inkrementace a expirace pomáhají počítat limit požadavků; přesný algoritmus časového okna je stále návrhové rozhodnutí.

Pub/Sub, Streams a zámky

Pub/Sub doručuje zprávu jen právě připojeným odběratelům; při odpojení se ztratí. Streams drží záznamy pro skupiny a umožňují jiný model zpracování. Zámek omezuje souběh, ale žádná z těchto funkcí sama nezaručí idempotentní businessový účinek.

Provozní vlastnosti

Perzistence, evikce a koordinace

Redis nabízí více než cache, ale každý účel přináší vlastní podmínky.

RDB snapshot: Bodový snímek dat v intervalech; při náhlém výpadku může chybět část posledních zápisů.
AOF: Append-only soubor zaznamenává operace; politika fsync určuje kompromis mezi výkonem a možnou ztrátou posledních zápisů.
Maxmemory a eviction: Při plné paměti Redis podle politiky maže klíče nebo odmítá zápisy. Pro cache je evikce přijatelná, pro jedinou kopii stavu ne.
Distribuovaný zámek: SET s NX a PX může krátce koordinovat práci. Uvolnění i prodloužení musí ověřit owner token.

Výhody a omezení

Rychlost nenahrazuje návrh dat

Přínosy

rychlé operace nad často čtenými a krátkodobými daty
TTL a atomické příkazy pro cache, čítače a koordinaci
sdílený dočasný stav pro více instancí aplikace
doplňuje relační databázi místo snahy ji ve všem nahradit

Na co pozor

TTL samo neřeší invalidaci a může vracet staré hodnoty
výpadek cache nemá znamenat výpadek aplikace ani stampede databáze
nekontrolovaný růst klíčů může vyčerpat paměť
Redis lock není záruka exactly once ani náhrada databázové ochrany

Hranice použití

Redis pomáhá, když rychlost a životnost odpovídají datům.

Je vhodný pro cache, krátkodobý stav, relace, kvóty a koordinaci, kde ztráta klíče nezničí autoritativní businessový záznam. Hodí se i tehdy, když více instancí aplikace potřebuje sdílet stejný dočasný stav.

Pro složité relační dotazy, dlouhodobou historii a účetní stopu není rychlost argumentem pro výměnu relační databáze. Před nasazením je dobré pojmenovat konkrétní úzké hrdlo i plán chování při nedostupnosti.

Na co myslet

Redis potřebuje limity, měření a fallback

Provozní bezpečnost závisí na pravidlech kolem serveru i aplikace.

prefixy klíčů a TTL odpovídající povaze dat
maxmemory a evikční politika odpovídající riziku ztráty
monitoring paměti, evikcí, latence, připojení a cache hit rate
test výpadku, restartu a současného cache miss
síťové zabezpečení, ACL a žádná citlivá data v klíčích

Časté otázky

Co Redis řeší a co ne

Je Redis databáze, nebo cache?

Technicky je to datové úložiště s vlastními strukturami a persistencí. V řadě aplikací slouží hlavně jako cache; rozhodující je, zda návrh umí snést jeho ztrátu.

Proč nestačí nastavit dlouhé TTL?

Dlouhé TTL sníží počet dotazů, ale prodlouží dobu, po kterou může aplikace vracet stará data. Je to kompromis doplněný invalidací při změně důležitých dat.

Může Redis nahradit PostgreSQL?

Pro jednoduchý use case může být autoritativním úložištěm, ale datový model, dotazování a provozní vlastnosti jsou jiné. Pro objednávky a dlouhodobou historii je relační databáze obvykle vhodnější.

Zajistí Redis zámek, že úloha proběhne jen jednou?

Ne úplně. Zámek omezuje souběh, ale při timeoutu, pádu procesu nebo failoveru zůstává nejistota. Výsledek úlohy má být idempotentní nebo chráněný i v autoritativním úložišti.

Jak Redis používám v praxi

Redis používám tam, kde dává smysl rychlý a krátkodobý stav.

V integračních službách pracuji s cache, koordinací a provozními omezeními podle konkrétního toku dat.

Jak Redis používám v praxi Nezávazně probrat projekt