NoSQL databáze jsou v roce 2012 stále kontroverzní téma v enterprise světě. Oracle a PostgreSQL tu panují desítky let a nikdo nemá chuť riskovat. Ale Redis — key-value store běžící kompletně v paměti — si našel místo i v nejkonzervativnějších architekturách. Ne jako náhrada relační DB, ale jako dokonalý doplněk.
Co je Redis a proč o něm mluvíme¶
Redis (Remote Dictionary Server) je open-source in-memory datová struktura. Na rozdíl od klasické databáze všechna data drží v RAM, což mu dává odezvu v řádu mikrosekund. Podporuje stringy, hashe, listy, sety, sorted sety a pub/sub messaging. Verze 2.6, aktuálně nejnovější, přidala Lua scripting.
Důležité: Redis není náhrada za Oracle. Nemá SQL, nemá transakce v tradičním smyslu, nemá joiny. Je to specializovaný nástroj pro specifické use casy — a v těch exceluje.
Use case #1: Cache vrstva před databází¶
Typický enterprise systém má problém: databáze je úzké hrdlo. Stovky uživatelů volají stejné dotazy — seznam produktů, konfigurační parametry, ciselníky. Každý dotaz putuje do Oracle, i když se data mění jednou za hodinu.
Redis řeší tento problém elegantně. Výsledek SQL dotazu serializujete (JSON nebo Java serialization) a uložíte do Redis s TTL (time to live). Další request čte z Redis — odpověď přijde za 0.1 ms místo 50 ms z databáze.
// Jednoduché cachování s Jedis klientem
Jedis jedis = new Jedis(“redis-server”, 6379);
String cached = jedis.get(“products:all”);
if (cached == null) {
List
cached = gson.toJson(products);
jedis.setex(“products:all”, 3600, cached); // TTL 1h
}
return gson.fromJson(cached, productListType);
V našem projektu pro pojišťovnu jsme tímto přístupem snížili zátěž na Oracle o 70 %. Response time API klesla z průměrných 200 ms na 15 ms pro cachované endpointy.
Use case #2: Session store pro clustered aplikace¶
Java EE aplikační servery (WebSphere, JBoss, WebLogic) ukládají HTTP session standardně do paměti serveru. Problém nastane, když máte cluster — dva nebo více serverů za load balancerem. Uživatel se přihlásí na server A, další request jde na server B a session tam není.
Řešení číslo jedna je sticky sessions (load balancer posílá uživatele vždy na stejný server). Ale to znamená nerovnoměrné rozložení zátěže a problém při výpadku serveru — session je ztracená.
Řešení číslo dva: session replication (servery si session kopírují mezi sebou). Funguje pro 2–3 servery, ale škáluje to špatně a žere síťovou kapacitu.
Řešení číslo tři — a to doporučujeme — je externalizovaná session v Redis. Všechny servery v clusteru čtou a zapisují session do jednoho Redis instance. Odezva je pod 1 ms, session přežije restart jakéhokoliv aplikačního serveru a škáluje se lineárně.
Spring Session (prototyp přístupu)¶
Spring Framework zatím nemá oficiální Redis session management (to přijde až ve Spring Session projektu za pár let), ale implementace vlastního HttpSessionListener, který serializuje session do Redis, je otázka jednoho odpoledne. Alternativně existuje knihovna tomcat-redis-session-manager pro Tomcat, která to řeší transparentně.
Persistence a bezpečnost dat¶
„Data v RAM? Co když server spadne?” — legitimní otázka. Redis nabízí dva persistence mechanismy: RDB snapshots (periodický dump celé databáze na disk) a AOF (append-only file, loguje každou write operaci).
Pro cache je persistence zbytečná — data se dají kdykoliv znovu vygenerovat z primární databáze. Pro session store doporučujeme AOF s fsync every second — ztratíte maximálně sekundu dat, což je akceptabilní kompromis.
Pro high availability v produkci používáme Redis Sentinel — automatický failover s master-slave replikací. Slave neustále kopíruje data z mastera a při výpadku se automaticky povýší na nového mastera. Výpadek trvá typicky 5–15 sekund.
Redis vs. Memcached¶
Memcached je starší a jednodušší alternativa. Pro čistý key-value caching funguje srovnatelně. Ale Redis má zásadní výhody:
- Datové struktury — listy, sety, sorted sety umožňují operace, které v Memcached vyžadují read-modify-write
- Persistence — Memcached po restartu ztratí všechna data
- Pub/Sub — Redis funguje i jako lightweight message broker
- Atomické operace — INCR, LPUSH, SADD jsou atomické bez locků
- Replikace — master-slave out of the box
Jedinou oblast, kde Memcached vyhrává, je multithreading. Redis je single-threaded (využívá jedno CPU jádro). V praxi to ale problém není — jedno jádro zvládne 100 000+ operací za sekundu.
Provozní zkušenosti¶
Redis na produkci provozujeme už rok. Paměťová stopa je překvapivě malá — 100 000 session objektů zabere kolem 2 GB RAM. Monitoring děláme přes redis-cli INFO a vlastní Nagios check, který sleduje used_memory, connected_clients a keyspace hit ratio.
Největší poučení: nastavte maxmemory a eviction policy. Bez toho Redis roste, dokud nesežere veškerou RAM serveru a OOM killer ho sestřelí. Pro cache používáme allkeys-lru (least recently used), pro session store noeviction (raději vrátit chybu než smazat session).
Shrnutí¶
Redis není revoluce, která nahradí vaši relační databázi. Je to chirurgicky přesný nástroj pro dva klíčové problémy: caching a session management. Nasazení je jednoduché, provoz nenáročný a výkonnostní zlepšení dramatické. Pokud váš systém trpí pomalými odpověďmi nebo problémy s clusterovanými session, Redis je odpověď.