RedisCache – Add-On für Znuny und OTRS CE

Redis-basiertes Cache-Backend für Znuny und OTRS CE

mxc-RedisCache ist ein Redis-basiertes Cache-Backend für OTRS/Znuny 6 und Znuny 7. Das Add-on ersetzt das dateisystembasierte Standard-Cache-Backend durch ein performantes Redis-Backend und bleibt dabei kompatibel zur bestehenden Cache-API des Frameworks.

Der Schwerpunkt liegt nicht darauf, OTRS oder Znuny grundsätzlich anders zu betreiben. Vielmehr stellt mxc-RedisCache eine zusätzliche Betriebsoption bereit: Cache-Daten können in Redis gespeichert werden, ohne dass Anwendungscode angepasst werden muss.

Das ist besonders interessant für Installationen mit höherem Cache-Aufkommen, für performancebewusste Setups und für Umgebungen, in denen Redis ohnehin als Infrastrukturkomponente verfügbar ist.

Kurzfassung

Redis-basiertes Cache-Backend für OTRS/Znuny 6 und Znuny 7
keine Anpassung von Anwendungscode notwendig
kompatibel zu Kernel::System::Cache
unterstützt Set, Get, Delete und CleanUp
Speicherung komplexer Datenstrukturen über die bestehende Storable-Serialisierung
optionale Nutzung von Redis oder Redis::Fast
optionale Passwort-Authentifizierung
erfolgreich getestet mit Redis, Valkey, Dragonfly und KeyDB
zusätzliche Namespace-Isolation für Installationen, die Redis gemeinsam nutzen

Warum Redis als Cache-Backend?

Viele OTRS- und Znuny-Installationen verwenden standardmäßig ein dateibasiertes Cache-Backend. Das ist funktional und für viele kleinere Installationen völlig ausreichend.

In größeren oder stärker belasteten Umgebungen kann ein Redis-basiertes Cache-Backend jedoch Vorteile bieten:

schnellere Cache-Zugriffe über einen spezialisierten In-Memory-Datenspeicher
zentrale Cache-Ablage statt lokaler Dateisystem-Caches
besser kontrollierbares Verhalten in Server- und Container-Umgebungen
einfachere Analyse und Überwachung über vorhandene Redis-Werkzeuge
Nutzung bestehender Redis-Infrastruktur

Robuste Speicherung komplexer Datenstrukturen

Gespeichert werden nicht nur einfache Zeichenketten, sondern auch komplexere Strukturen, die im OTRS-/Znuny-Cache üblich sind.

Unterstützt werden unter anderem:

Skalare
Arrays und Hashes
verschachtelte UTF-8-Strukturen
Scalar-Referenzen
binäre Payloads inklusive Nullbytes
leere Strings

Die Werte werden über die bestehende Storable-Komponente des Frameworks serialisiert. Dadurch bleibt das Backend nah an den vorhandenen Mechanismen von OTRS und Znuny.

Namespace-Isolation für besondere Betriebsszenarien

Viele Kunden betreiben nur eine einzelne OTRS- oder Znuny-Installation pro Redis-Instanz. Für diese Umgebungen ist Namespace-Isolation nicht der Hauptgrund für den Einsatz des Add-ons.

Trotzdem ist sie ein wichtiger Sicherheits- und Betriebsbaustein, sobald mehrere Installationen, Testumgebungen oder Staging-Systeme dieselbe Redis-Infrastruktur verwenden.

mxc-RedisCache arbeitet mit einem expliziten Namespace-Präfix. Cache-Cleanup bleibt dadurch auf den aktiven Namespace beschränkt. Das bedeutet:

keine versehentliche Löschung von Cache-Daten anderer Installationen
kein globales FLUSHDB für normales Cache-Cleanup
saubere Trennung von Produktiv-, Test- und Entwicklungsumgebungen, wenn diese gemeinsam Redis nutzen
kontrollierbares Verhalten auch bei mehreren Installationen innerhalb derselben Redis-Datenbank

Damit eignet sich das Add-on sowohl für einfache Einzelinstallationen als auch für komplexere Betriebsmodelle.

Geeignete Einsatzszenarien

mxc-RedisCache ist besonders interessant für:

OTRS- und Znuny-Installationen mit höherem Cache-Aufkommen
Systeme, bei denen Cache-Zugriffe performanter und zentraler abgebildet werden sollen
Umgebungen, in denen Redis bereits als Infrastrukturkomponente vorhanden ist
Container- und Server-Setups, in denen lokale Dateisystem-Caches ungünstig sind
Installationen mit mehreren Applikationsservern
Test-, Staging- und Produktionsumgebungen mit gemeinsamer oder vergleichbarer Redis-Infrastruktur

Für kleine Einzelinstallationen ohne Performance- oder Betriebsanforderungen ist Redis nicht automatisch ein spürbarer Vorteil. Der größte Nutzen entsteht dort, wo Cache-Zugriffe relevant sind oder Redis als zentrale Infrastruktur bewusst eingesetzt werden soll.