Redis

Beispiel: Twitter Timeline. Wenn du Twitter öffnest, muss es nicht 1 Milliarde Tweets durchsuchen. Deine Timeline liegt fertig berechnet in Redis. Zack, sie ist sofort da. Wenn du Twitter schließt, wird sie vielleicht gelöscht (LRU - Least Recently Used), um Platz für andere zu machen.

Praxisbeispiel: Ein Backend speichert das Ergebnis einer teuren API-Anfrage für 60 Sekunden. Beim nächsten gleichen Request kommt die Antwort aus Redis statt aus der langsamen Quelle.

Praxisroutine

In der Praxis lernst du Redis, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Persistenz

Obwohl In-Memory, kann Redis Daten speichern. Es macht alle paar Sekunden einen "Snapshot" auf die Festplatte (RDB). Oder es schreibt jeden Befehl mit (AOF - Append Only File). So überleben die Daten auch einen Neustart (meistens zumindest).

2. Datenstrukturen

Redis ist nicht nur "Key-Value" ("Name = Max"). Es versteht Listen, Sets (Mengen) und Hashes. Du kannst sagen: "Gib mir die Top 5 aus dieser Liste". Redis macht das in Nanosekunden, weil die Liste im RAM sortiert vorliegt.

Technisch wird Redis für Cache, Queue und Session-Store genutzt. Wichtig sind Ablaufzeiten, Cache-Miss-Verhalten und die Frage, ob Daten verloren gehen dürfen.

1. Single-Threaded Event Loop (Der asynchrone Tanz)

Die wohl schockierendste Tatsache: Redis läuft intern auf einem einzigen Thread (epoll/kqueue). Während relationale DBs pro Connect einen Linux/Java-Thread clonen, verarbeitet Redis nacheinander alle Memory-Ops. Warum skaliert es auf 100.000 QPS? Weil RAM-Zugriffe für die CPU unfassbar schnell sind (~100 Nanosekunden). Der Wechsel von Betriebssystem-Kontexten (Context Switching) und Locking-Mechanismen für Parallelität (Mutex) würde das System hart in Zeitstrafen lähmen. Der Single-Thread garantiert dir "Isolation/Atomizität": Ein INCR counter (Zähler hochsetzen) überschneidet sich nie mit einem anderen Request. Thread-Safety und Race Conditions sind in Redis by Design völlig ausgeschaltet, ohne teure Locking-Syntax zu bemühen.

2. AOF Rewrite und Fork() (Memory Pitfalls)

Redis persisitiert Daten mit AOF (Append Only File). Jeder Schreib-Befehl geht als String (SET user "Max") ans Ende eines Server-Logs. Das Log wächst absurd an. Redis nutzt AOF-Rewriting, um das Log zu stauchen. Es erstellt per Linux fork() Modus einen identischen Klon-Prozess seiner eigenen RAM-Seiten (Copy-on-Write). Der Klon-Prozess schaut in den RAM und schreibt ein brandneues, sauberes AOF-File (nur Endzustände) parallel auf die SSD. Geheimwaffe: Wenn während des 2-minütigen Klonens plötzliche Schreib-Spitzen passieren, beginnt Linux massenhaft RAM Pages physisch zu duplizieren. Ein Redis, das 30 GB auf einem 32 GB Server belebt, reißt plötzlich den Klon-Prozess bei Last mit 60GB RAM an und wird vom Kernel lautstark hingerichtet (OOM-Killer).

3. Redis Sentinel & Cluster (Distributed Hashing)

Ein normaler Redis Server ist ab 50 GB voll. Für echte "Web-Scale" Cloud bedarf es Split (Partitioning/Sharding) -> Redis Cluster. Redis teilt seinen Keyspace gnadenlos in 16.384 Hash Slots. Wirft man SET user123 ein, hasht der Client den Key = Hash-Slot 5000. Server B sagt dem SDK: "Ich halte Slot 5000, sende es mir!". Wenn ein Server abbrennt, wählt Redis Sentinel (eine Gossip-Protokoll P2P Miliz-Software im Hintergrund) vollautomatisch binnen 3 Sekunden asynchron einen von mehreren read-only Slave-Containern zum neuen Warlord (Master) hoch. Split-Brain Bugs müssen dabei durch Majority-Quorums (Knotenanzahl) unterbunden werden, damit zwei Leader in Netz-Partitionen nicht synchron schreiben.