Magento Cache-Backend: Konfiguration im Detail

1. Warum Redis als Cache-Backend

Der Standard-Cache von Magento speichert serialisierte Daten als Dateien im Dateisystem unter var/cache. Bei jedem Seitenaufruf liest Magento Dutzende Cache-Eintraege, etwa Konfiguration, Layout-XML, Block-HTML und EAV-Attribute. Auf einem einzelnen Server mit schnellem SSD faellt das kaum auf, doch sobald mehrere Webserver hinter einem Load Balancer laufen, wird das dateibasierte Cache-Backend zum Problem: Jeder Server pflegt seinen eigenen Cache-Stand, Invalidierungen greifen nicht serverweit, und NFS-Mounts als gemeinsamer Speicher erzeugen zusaetzliche Latenz statt sie zu beseitigen.

Ein Redis Cache-Backend loest dieses Problem, indem es den Cache aus dem Dateisystem in einen zentralen In-Memory-Speicher verlagert, auf den alle Webserver gleichzeitig zugreifen. Lesezugriffe liegen im Bereich von unter einer Millisekunde, Schreibzugriffe sind atomar, und Invalidierungen wirken sofort auf allen Knoten. Magento nutzt dafuer die Backend-Klasse Cm_Cache_Backend_Redis, die als Composer-Abhaengigkeit colinmollenhour/cache-backend-redis mitgeliefert wird und speziell fuer Zend-Framework-kompatible Cache-Tags optimiert ist.

Voraussetzung ist die PHP-Erweiterung redis (phpredis) oder ein kompatibler Predis-Fallback, sowie ein erreichbarer Redis-Server ab Version 5.0, empfohlen wird Redis 7.x fuer Magento 2.4.8. Das Cache-Backend laesst sich getrennt von Session- und Full-Page-Cache-Speicher konfigurieren, was in der Praxis fast immer sinnvoll ist, weil die drei Rollen unterschiedliche Zugriffsmuster und Speicheranforderungen haben.

2. env.php Grundstruktur der cache-Sektion

Die Konfiguration des Cache-Backends erfolgt vollstaendig in app/etc/env.php unter dem Schluessel cache. Diese Sektion enthaelt ein frontend-Array mit benannten Cache-Frontends, wobei default als Fallback fuer alle Magento-Cache-Typen dient, die keine explizite Zuordnung haben. Jeder Cache-Typ, etwa config, layout, block_html oder full_page, kann bei Bedarf einem eigenen Frontend zugewiesen werden, was in der Praxis meist nur fuer den Full-Page-Cache getrennt vom restlichen Cache-Backend genutzt wird.

Innerhalb eines Frontend-Eintrags legt backend die PHP-Klasse fest, die Magento fuer dieses Cache-Backend instanziiert. Fuer Redis ist das Cm_Cache_Backend_Redis. Der Schluessel backend_options nimmt ein Array mit allen Verbindungs- und Verhaltensparametern auf, die im weiteren Verlauf dieses Artikels im Detail erklaert werden. Optional steuert frontend_options Zend-Cache-Frontend-Verhalten wie automatische Serialisierung, was fuer das Redis-Backend in der Regel auf den Magento-Standardwerten belassen wird.

<?php
// app/etc/env.php - cache section, Redis as default Cache-Backend
return [
    // ... other env.php keys omitted for brevity
    'cache' => [
        'frontend' => [
            'default' => [
                'backend' => 'Cm_Cache_Backend_Redis',
                'backend_options' => [
                    'server' => '127.0.0.1',
                    'port' => '6379',
                    'database' => '0',
                    'password' => '',
                    'compress_data' => '1',
                    'compress_tags' => '1',
                    'compress_threshold' => '20480',
                    'compression_lib' => 'gzip',
                ],
            ],
            'page_cache' => [
                'backend' => 'Cm_Cache_Backend_Redis',
                'backend_options' => [
                    'server' => '127.0.0.1',
                    'port' => '6379',
                    'database' => '1',
                    'compress_data' => '0',
                ],
            ],
        ],
    ],
];

3. Cm_Cache_Backend_Redis im Detail

Die Klasse Cm_Cache_Backend_Redis implementiert das Zend-Cache-Backend-Interface und uebersetzt Zend-Cache-Operationen wie save, load und clean in Redis-Kommandos. Anders als generische Redis-Cache-Adapter beruecksichtigt dieses Cache-Backend die Tag-basierte Invalidierung, die Magento fuer den Konfigurations- und Layout-Cache voraussetzt. Ohne diese Tag-Unterstuetzung wuerde bin/magento cache:clean config nicht funktionieren, weil generische Redis-Clients keine Vorstellung von Cache-Tags haben.

Intern legt das Cache-Backend fuer jeden Cache-Eintrag einen Hauptschluessel mit dem Praefix zc:k: an, dazu Metadaten-Schluessel fuer Tags und Ablaufzeiten. Beim Speichern eines Eintrags mit Tags aktualisiert das Backend zusaetzlich Tag-zu-ID-Zuordnungen als Redis-Sets, sodass clean(Zend_Cache::CLEANING_MODE_MATCHING_TAG) effizient alle betroffenen Eintraege findet, ohne den gesamten Keyspace zu scannen. Diese Datenstruktur ist der Grund, warum das Redis-Cache-Backend bei taggebundener Invalidierung deutlich schneller ist als ein dateibasiertes Backend mit Verzeichnis-Scans.

4. Datenbank-Index-Trennung im Cache-Backend

Der Parameter database im backend_options-Array waehlt eine der 16 logischen Redis-Datenbanken (Index 0 bis 15 in der Standardkonfiguration) innerhalb derselben Redis-Instanz aus. Wird fuer das Cache-Backend derselbe Index wie fuer Session-Speicher oder Full-Page-Cache verwendet, landen alle Schluessel im selben Namensraum. Ein FLUSHDB, das eigentlich nur den Konfigurations-Cache leeren sollte, kann dann versehentlich aktive Sessions mitloeschen.

Die uebliche Praxis ist, dem allgemeinen Cache-Backend Index 0 zuzuweisen, dem Full-Page-Cache Index 1 und dem Session-Speicher Index 2. Diese Trennung kostet nichts an Performance, weil alle Indizes innerhalb derselben Redis-Instanz und desselben Prozesses liegen, reduziert aber operative Risiken erheblich. Fuer sehr grosse Installationen mit hohem Session- oder Cache-Volumen ist zusaetzlich eine physische Trennung auf getrennte Redis-Instanzen sinnvoll, was jedoch eine eigene Betriebsentscheidung jenseits der reinen Datenbank-Index-Wahl ist.

5. Kompression: compress_data, compress_tags, compress_threshold

Grosse Cache-Eintraege wie serialisiertes Layout-XML oder vollstaendiges Block-HTML koennen mehrere hundert Kilobyte umfassen. Ohne Kompression multipliziert sich dieser Speicherbedarf schnell ueber tausende Eintraege im Cache-Backend. Der Parameter compress_data aktiviert die Kompression der Nutzdaten, waehrend compress_tags separat steuert, ob auch die Tag-Metadaten komprimiert werden. Beide Werte akzeptieren 0 oder 1 als String.

compress_threshold legt in Byte fest, ab welcher Groesse ein Eintrag ueberhaupt komprimiert wird, Standardwert ist 20480 Byte, also 20 Kilobyte. Kleinere Eintraege werden unkomprimiert gespeichert, weil der CPU-Overhead der Kompression bei kleinen Werten den Speichergewinn nicht rechtfertigt. compression_lib waehlt den Algorithmus: gzip ist ueberall verfuegbar und bietet gute Kompressionsraten bei moderater CPU-Last, lzf und snappy sind schneller, aber komprimieren schwaecher und erfordern zusaetzliche PHP-Erweiterungen. Fuer die meisten Magento-Shops ist gzip im Cache-Backend die sinnvolle Standardwahl, weil CPU auf dem Webserver meist reichlicher vorhanden ist als RAM auf dem Redis-Server.

<?php
// app/etc/env.php - Cache-Backend with tuned compression for large layouts
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
                'compress_data' => '1',
                'compress_tags' => '1',
                // Only compress entries larger than 8 KB to save CPU on small entries
                'compress_threshold' => '8192',
                'compression_lib' => 'gzip',
                'automatic_cleaning_factor' => '0',
            ],
        ],
    ],
],

6. Wie Magento Cache-Tags in Redis speichert

Cache-Tags sind das Kernkonzept, das das Redis-Cache-Backend von einem einfachen Key-Value-Speicher unterscheidet. Wenn Magento einen Block-HTML-Eintrag speichert, haengt es Tags wie CATALOG_PRODUCT_123 oder FPC an. Aendert sich ein Produkt, ruft Magento clean(MATCHING_TAG, ['CATALOG_PRODUCT_123']) auf, und das Cache-Backend loescht gezielt alle Eintraege mit diesem Tag, ohne andere Cache-Daten anzuruehren.

In Redis sieht man diese Struktur direkt mit redis-cli: Schluessel mit Praefix zc:ta: enthalten Sets von Cache-IDs pro Tag, waehrend zc:td:-Schluessel die IDs verwalten, die bereits geloescht wurden. Mit SMEMBERS zc:ta:CATALOG_PRODUCT_123 laesst sich pruefen, welche Cache-Eintraege aktuell mit einem bestimmten Tag verknuepft sind, was beim Debugging von Invalidierungsproblemen im Cache-Backend sehr hilfreich ist.

# Inspect Cache-Backend keys and tag structures directly in Redis
redis-cli -n 0 KEYS "zc:k:*" | head -20
redis-cli -n 0 SMEMBERS "zc:ta:CATALOG_PRODUCT_123"
redis-cli -n 0 TTL "zc:k:CACHE_ENTRY_ID"

# Count total keys in the Cache-Backend database
redis-cli -n 0 DBSIZE

# Check memory used specifically by the cache database
redis-cli -n 0 INFO keyspace

7. Verbindungsoptionen: persistent, timeout, retry

Der Parameter persistent im Cache-Backend aktiviert persistente PHP-FPM-Verbindungen zu Redis, identifiziert ueber einen frei waehlbaren String als Connection-ID. Das spart den TCP-Handshake bei jedem Request, funktioniert aber nur zuverlaessig mit phpredis, nicht mit Predis. In containerisierten Umgebungen mit kurzlebigen PHP-FPM-Prozessen bringt persistent meist wenig, in klassischen Langzeit-Worker-Setups kann es spuerbar Latenz sparen.

connect_retries legt fest, wie oft das Cache-Backend einen fehlgeschlagenen Verbindungsaufbau wiederholt, bevor eine Exception geworfen wird, Standardwert ist 1. read_timeout begrenzt in Sekunden, wie lange Magento auf eine Redis-Antwort wartet. Wird dieser Wert zu niedrig gesetzt, brechen grosse Cache-Reads unter Last ab, wird er zu hoch gesetzt, haengen Requests bei einem Redis-Ausfall unnoetig lange. Ein Wert zwischen 2.5 und 10 Sekunden hat sich fuer produktive Magento-Installationen bewaehrt.

<?php
// app/etc/env.php - Cache-Backend connection tuning for long-running workers
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
                'persistent' => 'magento-cache-pool',
                'connect_retries' => '2',
                'read_timeout' => '5',
            ],
        ],
    ],
],

8. Monitoring und Debugging des Cache-Backends

bin/magento cache:status zeigt, welche Cache-Typen aktiv sind, sagt aber nichts ueber den Zustand des Redis-Cache-Backends selbst aus. Fuer echte Diagnose ist redis-cli INFO der Einstiegspunkt: Der Abschnitt memory zeigt used_memory_human und maxmemory_policy, der Abschnitt stats zeigt keyspace_hits und keyspace_misses, deren Verhaeltnis die effektive Trefferquote des Cache-Backends widerspiegelt.

Eine niedrige Trefferquote deutet meist auf zu kurze TTLs, eine zu kleine maxmemory-Grenze mit aggressiver Eviction oder auf haeufige, breite Invalidierungen hin. redis-cli --bigkeys findet ueberdimensionierte Eintraege, die auf fehlende Kompression oder ungewoehnlich grosse Layout-Bloecke hinweisen. In der Produktion sollte MONITOR nur kurzzeitig und mit Vorsicht eingesetzt werden, da es jeden einzelnen Befehl protokolliert und bei hohem Durchsatz selbst zur Last werden kann.

# Core hit-rate and memory diagnostics for the Cache-Backend
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_policy"

# Find oversized entries that may be missing compression
redis-cli --bigkeys

# Confirm which cache types are enabled at the application level
bin/magento cache:status

9. Redis Cache-Backend im Vergleich zum File-System-Backend

Die Wahl des Cache-Backends beeinflusst Latenz, Skalierbarkeit und operativen Aufwand gleichermassen. Fuer Single-Server-Setups mit wenig Traffic mag das dateibasierte Backend ausreichen, fuer alles darueber hinaus ist Redis die technisch ueberlegene Wahl.

In der Praxis ist die Entscheidung fuer produktive Shops fast immer eindeutig: Sobald mehr als ein Webserver im Einsatz ist oder Skalierbarkeit absehbar wird, ist ein Redis-Cache-Backend Voraussetzung fuer verlaessliches Verhalten. Der einzige Trade-off ist der zusaetzliche Betriebsaufwand fuer den Redis-Server selbst, der jedoch mit Standard-Monitoring gut beherrschbar ist.

10. Zusammenfassung

Das Redis Cache-Backend in Magento wird vollstaendig ueber app/etc/env.php konfiguriert, mit der Backend-Klasse Cm_Cache_Backend_Redis und einem backend_options-Array, das Server, Port, Datenbank-Index, Kompression und Verbindungsverhalten steuert. Die Trennung ueber Datenbank-Indizes verhindert Kollisionen zwischen Cache, Session und Full-Page-Cache. Kompression mit compress_data, compress_tags und compress_threshold reduziert den Speicherbedarf grosser Layout- und Block-Eintraege spuerbar.

Wer das Cache-Backend richtig konfiguriert, profitiert von millisekundenschnellen Lesezugriffen, konsistentem Cache-Stand ueber mehrere Webserver hinweg und einer effizienten, tag-basierten Invalidierung, die gezielt nur betroffene Eintraege loescht. Monitoring ueber redis-cli INFO und regelmaessige Pruefung der Trefferquote sind die Grundlage, um das Cache-Backend dauerhaft im gesunden Zustand zu halten.

11. FAQ: Magento Cache-Backend mit Redis