NoSQL: Redis als Cache und Session Store

NoSQL-Datenbanken sind 2012 nach wie vor ein kontroverses Thema in der Enterprise-Welt. Oracle und PostgreSQL herrschen seit Jahrzehnten und niemand ist bereit, Risiken einzugehen. Doch Redis — ein Key-Value Store, der vollständig im Arbeitsspeicher läuft — hat sich selbst in den konservativsten Architekturen einen Platz erobert. Nicht als Ersatz für eine relationale Datenbank, sondern als perfekte Ergänzung.

Was Redis ist und warum wir darüber sprechen¶

Redis (Remote Dictionary Server) ist ein quelloffener In-Memory-Datenstrukturspeicher. Anders als eine klassische Datenbank hält er alle Daten im RAM, was ihm Antwortzeiten im Bereich von Mikrosekunden ermöglicht. Er unterstützt Strings, Hashes, Listen, Sets, Sorted Sets und Pub/Sub-Messaging. Version 2.6, die aktuell neueste, hat Lua-Scripting hinzugefügt.

Wichtig: Redis ist kein Ersatz für Oracle. Es gibt kein SQL, keine Transaktionen im traditionellen Sinne, keine Joins. Es ist ein spezialisiertes Werkzeug für bestimmte Anwendungsfälle — und in diesen glänzt es.

Anwendungsfall #1: Cache-Schicht vor der Datenbank¶

Ein typisches Enterprise-System hat ein Problem: Die Datenbank ist der Flaschenhals. Hunderte von Benutzern rufen die gleichen Abfragen ab — Produktliste, Konfigurationsparameter, Nachschlagetabellen. Jede Abfrage geht an Oracle, obwohl sich die Daten nur einmal pro Stunde ändern.

Redis löst dieses Problem elegant. Man serialisiert das SQL-Abfrageergebnis (JSON oder Java-Serialisierung) und speichert es in Redis mit einer TTL (Time to Live). Die nächste Anfrage liest aus Redis — die Antwort kommt in 0,1 ms statt 50 ms aus der Datenbank.

// Einfaches Caching mit dem Jedis-Client
Jedis jedis = new Jedis("redis-server", 6379);
String cached = jedis.get("products:all");
if (cached == null) {
  List<Product> products = dao.findAll();
  cached = gson.toJson(products);
  jedis.setex("products:all", 3600, cached); // TTL 1h
}
return gson.fromJson(cached, productListType);

In unserem Projekt für eine Versicherungsgesellschaft haben wir mit diesem Ansatz die Last auf Oracle um 70 % reduziert. Die API-Antwortzeit sank von durchschnittlich 200 ms auf 15 ms für gecachte Endpunkte.

Anwendungsfall #2: Session Store für geclusterte Anwendungen¶

Java-EE-Applikationsserver (WebSphere, JBoss, WebLogic) speichern HTTP-Sessions standardmäßig im Arbeitsspeicher des Servers. Das Problem entsteht bei einem Cluster — zwei oder mehr Server hinter einem Load Balancer. Ein Benutzer meldet sich auf Server A an, die nächste Anfrage geht an Server B, und die Session ist dort nicht vorhanden.

Lösung eins sind Sticky Sessions (der Load Balancer schickt einen Benutzer immer zum gleichen Server). Das bedeutet aber ungleichmäßige Lastverteilung und ein Problem bei Serverausfall — die Session geht verloren.

Lösung zwei ist Session Replication (Server kopieren Sessions untereinander). Das funktioniert bei 2–3 Servern, skaliert aber schlecht und verbraucht Netzwerkkapazität.

Lösung drei — und die von uns empfohlene — ist eine externalisierte Session in Redis. Alle Server im Cluster lesen und schreiben Sessions in eine einzelne Redis-Instanz. Die Antwortzeit liegt unter 1 ms, Sessions überleben den Neustart jedes Applikationsservers und das System skaliert linear.

Spring Session (Prototyp-Ansatz)¶

Spring Framework hat noch kein offizielles Redis-Session-Management (das kommt erst mit dem Spring-Session-Projekt in ein paar Jahren), aber die Implementierung eines eigenen HttpSessionListener, der Sessions in Redis serialisiert, ist eine Nachmittagsarbeit. Alternativ gibt es die tomcat-redis-session-manager-Bibliothek für Tomcat, die das transparent handhabt.

Persistenz und Datensicherheit¶

„Daten im RAM? Was passiert, wenn der Server abstürzt?” — eine berechtigte Frage. Redis bietet zwei Persistenz-Mechanismen: RDB Snapshots (periodischer Dump der gesamten Datenbank auf die Festplatte) und AOF (Append-Only File, protokolliert jede Schreiboperation).

Für Cache ist Persistenz unnötig — Daten können jederzeit aus der primären Datenbank neu generiert werden. Für Session Storage empfehlen wir AOF mit fsync every second — Sie verlieren höchstens eine Sekunde an Daten, was ein akzeptabler Kompromiss ist.

Für Hochverfügbarkeit in der Produktion nutzen wir Redis Sentinel — automatisches Failover mit Master-Slave-Replikation. Der Slave kopiert kontinuierlich Daten vom Master und wird bei einem Ausfall automatisch zum neuen Master befördert. Das Failover dauert typischerweise 5–15 Sekunden.

Redis vs. Memcached¶

Memcached ist eine ältere und einfachere Alternative. Für reines Key-Value-Caching ist die Leistung vergleichbar. Aber Redis hat erhebliche Vorteile:

• Datenstrukturen — Listen, Sets und Sorted Sets ermöglichen Operationen, die in Memcached Read-Modify-Write-Zyklen erfordern
• Persistenz — Memcached verliert bei einem Neustart alle Daten
• Pub/Sub — Redis funktioniert auch als leichtgewichtiger Message Broker
• Atomare Operationen — INCR, LPUSH, SADD sind atomar ohne Locks
• Replikation — Master-Slave direkt verfügbar

Der einzige Bereich, in dem Memcached gewinnt, ist Multithreading. Redis ist Single-Threaded (nutzt einen CPU-Kern). In der Praxis ist das kein Problem — ein einzelner Kern schafft 100.000+ Operationen pro Sekunde.

Betriebserfahrung¶

Wir betreiben Redis seit einem Jahr in der Produktion. Der Speicherbedarf ist überraschend gering — 100.000 Session-Objekte belegen etwa 2 GB RAM. Wir überwachen über redis-cli INFO und einen eigenen Nagios-Check, der used_memory, connected_clients und die Keyspace Hit Ratio verfolgt.

Die wichtigste Lektion: Setzen Sie maxmemory und eine Eviction Policy. Ohne das wächst Redis, bis es den gesamten Server-RAM verbraucht und der OOM Killer zuschlägt. Für Cache verwenden wir allkeys-lru (Least Recently Used), für Session Storage noeviction (lieber einen Fehler zurückgeben als eine Session löschen).

Zusammenfassung¶

Redis ist keine Revolution, die Ihre relationale Datenbank ersetzen wird. Es ist ein chirurgisch präzises Werkzeug für zwei zentrale Probleme: Caching und Session Management. Die Bereitstellung ist einfach, der Betrieb unkompliziert und die Leistungsgewinne dramatisch. Wenn Ihr System unter langsamen Antwortzeiten oder Problemen mit geclusterten Sessions leidet, ist Redis die Antwort.