Wann Redis sinnvoll ist

Einsatzgebiete für den Hochleistungscache

Redis wird oft mit einem einfachen Versprechen verbunden: schneller. Das stimmt in vielen Szenarien, aber nicht in jeder einzelnen lokalen Vergleichsmessung.

Gerade bei Znuny auf einem einzelnen Server kann ein dateibasiertes Cache-Backend lokal durchaus schneller wirken als ein externer Redis-Zugriff. Das ist kein Widerspruch und auch kein Fehler. Redis löst nicht nur ein Performance-Thema, sondern vor allem bestimmte Betriebs- und Architekturfragen.

Kurz gesagt

Redis ist nicht in erster Linie dafür da, jeden lokalen File-Cache auf demselben Host zu schlagen. Redis ist vor allem dann interessant, wenn ein Cache:

  • von mehreren Prozessen oder Systemen gemeinsam genutzt werden soll
  • zentral verwaltet werden soll
  • kurzlebige Daten mit TTL sauber halten soll
  • über Installationsgrenzen hinweg strukturiert getrennt werden soll
  • mehr sein soll als nur ein lokaler Ablageort auf einer Maschine

Typische Einsatzszenarien von Redis

1. Cache für teure Berechnungen oder Datenbankzugriffe

Das ist der klassische Fall. Ergebnisse, die oft gebraucht werden, aber teuer zu berechnen oder zu laden sind, werden für eine gewisse Zeit zwischengespeichert.

Beispiele:

  • aufwendig aufgebaute Übersichten
  • häufig genutzte Konfigurationen
  • Ergebnisse von API-Aufrufen
  • vorberechnete Datenstrukturen

2. Gemeinsamer Cache für mehrere Anwendungsserver

Sobald nicht mehr nur ein einzelner Server beteiligt ist, wird ein rein lokaler Dateicache schnell unpraktisch. Jeder Knoten hätte sonst seinen eigenen Stand.

Redis ist hier nützlich, weil mehrere Systeme denselben Cache sehen und nutzen können.

3. Sessions und kurzlebiger Anwendungszustand

Viele Webanwendungen legen Sessions, Tokens oder andere kurzlebige Zustände in Redis ab. Dafür ist Redis gut geeignet, weil Werte schnell gelesen werden können und automatisch ablaufen dürfen.

4. Rate Limiting und Zähler

Wenn Zugriffe begrenzt werden sollen, zum Beispiel „maximal 100 Anfragen pro Minute“, ist Redis ein sehr passender Baustein. Zähler und Ablaufzeiten gehören zu den Standardfällen.

5. Queues und Hintergrundjobs

Redis wird oft verwendet, um Aufgaben zwischen Prozessen zu übergeben. Ein Prozess schreibt Jobs in eine Queue, andere Prozesse arbeiten sie später ab.

6. Pub/Sub und einfache Echtzeit-Signale

Wenn Prozesse einander Ereignisse mitteilen sollen, kann Redis auch als einfacher Verteiler dienen. Das ist kein Muss für Znuny-Cache, zeigt aber gut, dass Redis mehr ist als nur ein schneller Schlüssel-Wert-Speicher.

Wann Redis für Znuny sinnvoll sein kann

Für Znuny ist Redis nicht automatisch die beste Wahl. Es gibt aber klare Szenarien, in denen Redis einen echten Mehrwert bietet.

Sinnvoll ist Redis oft dann, wenn …

  • mehrere Znuny-Instanzen oder Webknoten denselben Cache nutzen sollen

  • Cache-Daten nicht nur lokal in Dateien auf einem Host liegen sollen
  • eine Umgebung bereits bewusst mit Redis arbeitet und das Betriebsmodell dazu passt
  • Cache-Daten sauber per Namespace und Datenbank getrennt werden sollen

  • Das Ticketsystem über den Cache mit Anwendungen austauschen soll

  • verteilte oder containerisierte Setups aufgebaut werden, in denen lokales Dateicaching unpraktisch ist

Gerade für dieses Modul ist Mehrinstallationsbetrieb ein wichtiger Punkt. Mehrere Znuny-Instanzen können auf demselben Redis-Server arbeiten, ohne sich gegenseitig zu überschreiben, wenn DatabaseNumber und Namespace sauber gesetzt sind.

Wann FileStorage oft die bessere Wahl ist

Es ist völlig legitim, beim dateibasierten Cache zu bleiben. In vielen lokalen Setups ist das die einfachere und schnellere Lösung.

FileStorage passt oft besser, wenn …

  • nur ein einzelner Znuny-Server betrieben wird
  • maximale lokale Geschwindigkeit wichtiger ist als zentrale Cache-Sichtbarkeit
  • keine verteilte Architektur vorhanden ist
  • die zusätzliche Redis-Infrastruktur keinen klaren Mehrwert bringt
  • Betrieb und Fehlersuche möglichst einfach bleiben sollen

Warum Redis trotz langsamerem lokalem Benchmark sinnvoll sein kann

Die zentrale Frage lautet nicht nur: „Was ist auf einer Maschine im Mikro-Benchmark schneller?“ Sondern auch: „Welches Backend passt besser zum tatsächlichen Betrieb?“

Redis kann sinnvoll sein, obwohl lokales FileStorage schneller ist, weil Redis andere Vorteile bringt:

  • gemeinsamer Cache über mehrere Systeme hinweg
  • saubere TTL-basierte Lebensdauer ohne lokale Dateiaufräumlogik
  • kontrolliertere Trennung mehrerer Installationen
  • zentrale Betriebs- und Infrastrukturmodelle, die ohnehin auf Redis setzen
  • geringere Bindung an lokales Dateisystemverhalten

Kurz gesagt: FileStorage kann lokal schneller sein. Redis kann betrieblich trotzdem die bessere Entscheidung sein.

Was Redis nicht verspricht

Redis ist kein Wundermittel. Diese Erwartungen sollen nicht geweckt werden:

  • Redis macht nicht automatisch jede Znuny-Installation schneller.
  • Redis ist nicht automatisch besser als lokaler FileStorage.
  • Redis ersetzt keine saubere Cache-Strategie.
  • Redis ist nicht notwendig, nur weil es modern oder verbreitet ist.

Eine einfache Entscheidungshilfe

Wenn die meisten Antworten hier „ja“ sind, sollte man Redis ernsthaft prüfen:

  • Gibt es mehrere Znuny-Knoten oder mehrere Installationen mit gemeinsamem Betriebsmodell?

  • Ist ein zentraler Cache fachlich oder betrieblich nützlich, zum Beispiel für die Kommunikation zwischen Instanzen oder Applikationen?

  • Wird Redis in der Umgebung ohnehin bereits zuverlässig betrieben?
  • Ist lokale Spitzen-Performance nicht das einzige Entscheidungskriterium?

Wenn die meisten Antworten „nein“ sind und ein einzelner Server lokal sehr gut mit FileStorage läuft, ist es oft vernünftig, beim Dateicache zu bleiben.

Fazit

Redis ist nicht die pauschal schnellere Variante für jeden Znuny-Server. Redis ist vor allem eine gute Lösung für zentrale, geteilte, kurzlebige und sauber getrennte Cache- und Zustandsdaten.

Wer nur einen einzelnen Server betreibt und lokal die beste reine Cache-Geschwindigkeit sucht, kann mit FileStorage sehr gut bedient sein.

Wer dagegen mehrere Systeme koordinieren, Cache-Zustände zentralisieren oder Betriebsmodelle mit Redis sauber unterstützen will, hat mit Redis ein sinnvolles Werkzeug, auch wenn ein lokaler Dateicache im direkten Vergleich manchmal schneller wirkt.

Für unsere Hosting- und Supportkunden ist die Nutzung unseres RedisCache Add-ons kostenlos im Paket enthalten.

Für Nichtkunden beträgt der Kaufpreis 500,- EUR zzgl. der gesetzlichen Mehrwertsteuer.

Das maxence RedisCache Add-On ist kompatibel mit Znuny und der ((OTRS)) Community Edition 6.