Symfony Cache: Komplexe Multi-Layer-Caching-Strategien

1. Die drei Cache-Ebenen in Symfony

Eine durchdachte Symfony Cache-Architektur arbeitet mit mehreren Ebenen, die unterschiedliche Kompromisse zwischen Geschwindigkeit und Reichweite eingehen. Die erste Ebene — L1 — ist der In-Process-Cache. APCu speichert Daten direkt im Shared Memory des PHP-Prozesses, ohne Netzwerklatenz, ohne Serialisierungsaufwand: Zugriffe liegen im Mikrosekunden-Bereich. Die zweite Ebene — L2 — ist der verteilte Cache. Redis oder Memcached speichern Daten prozessübergreifend und werden von allen PHP-Prozessen auf allen Servern geteilt. Zugriffe dauern Millisekunden durch Netzwerk-Round-Trip und Serialisierung, aber der Cache überlebt Prozess-Neustarts und teilt Daten im Cluster.

Die dritte Ebene — L3 — ist der HTTP-Cache. Varnish, Nginx oder der eingebaute Symfony Cache-Reverse-Proxy speichert komplette HTTP-Responses und liefert sie ohne PHP-Ausführung aus. Das spart die gesamte Applikationslogik, Datenbankabfragen und Templating für gecachte Responses. Diese drei Ebenen sind in Symfony Cache nahtlos integrierbar und ergänzen sich: L1 für häufig abgefragte Hot-Data im selben Request, L2 für shared State und längere TTLs, L3 für statische oder semi-statische Seiten mit hohem Traffic. Wer alle drei konsequent einsetzt, reduziert Datenbankabfragen und PHP-Execution-Time dramatisch.

2. PSR-6 und PSR-16: Cache-Interfaces richtig nutzen

Symfony implementiert beide Cache-PSR-Standards: PSR-6 (CacheItemPoolInterface) für den vollständigen, feature-reichen Cache mit expliziten Item-Objekten und PSR-16 (SimpleCache) für einfache Key-Value-Operationen. Services sollten gegen diese Interfaces typisiert werden, nicht gegen konkrete Adapter-Klassen. Der Symfony Cache-DI-Container injiziert automatisch den konfigurierten Adapter, wenn ein Service ein PSR-Interface als Dependency deklariert. Durch Interface-Typisierung bleibt der Service testbar — in Unit-Tests ersetzt man den echten Adapter durch ein Array- oder In-Memory-Adapter, ohne den Service-Code zu ändern.

Der Symfony-Wrapper Symfony\Contracts\Cache\CacheInterface kombiniert PSR-6 mit einem ergonomischeren API. Die Methode $cache->get('key', $callback) implementiert das Cache-Aside-Pattern in einer einzigen Zeile: Ist der Wert gecacht, wird er sofort zurückgegeben. Ist er nicht gecacht, wird $callback aufgerufen, das Ergebnis gecacht und zurückgegeben. Dieses Pattern verhindert duplizierten Cache-Lade-Code und ist die empfohlene Symfony Cache-API für die meisten Anwendungsfälle. Der Callback erhält ein CacheItemInterface, auf dem man TTL, Tags und andere Metadaten setzen kann.

<?php

declare(strict_types=1);

namespace App\Repository;

use App\Entity\Product;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Contracts\Cache\CacheInterface;
use Symfony\Contracts\Cache\ItemInterface;

/**
 * Product repository with multi-layer Symfony Cache integration.
 */
final readonly class CachedProductRepository
{
    public function __construct(
        private EntityManagerInterface $em,
        private CacheInterface $cache,  // injected from framework.cache.app
    ) {}

    /**
     * Cache-aside pattern: load from cache, compute on miss.
     * Tags enable targeted invalidation by product or category.
     */
    public function findFeaturedProducts(): array
    {
        return $this->cache->get('products.featured', function (ItemInterface $item): array {
            // Set TTL and tags for targeted invalidation
            $item->expiresAfter(3600);  // 1 hour TTL
            $item->tag(['products', 'products.featured']);

            // This only runs on cache miss — no DB query on hits
            return $this->em
                ->createQuery('SELECT p FROM App\Entity\Product p WHERE p.featured = true')
                ->getResult();
        });
    }

    /**
     * Invalidate all product caches when a product changes.
     */
    public function invalidateProductCaches(): void
    {
        // TagAwareCacheInterface required for tag-based invalidation
        if ($this->cache instanceof \Symfony\Contracts\Cache\TagAwareCacheInterface) {
            $this->cache->invalidateTags(['products']);
        }
    }
}

3. APCu als L1-Cache: In-Process-Geschwindigkeit

APCu speichert Daten im PHP-Shared-Memory, das von allen Worker-Prozessen des gleichen PHP-FPM-Pools geteilt wird. Das macht APCu zum schnellsten verfügbaren Cache-Adapter in Symfony Cache: Kein Netzwerk, kein Serialisierungs-Overhead durch externe Services, nur ein Speicherbereich-Lookup. Typische Zugriffzeiten liegen unter einer Millisekunde und machen APCu ideal für Konfigurationswerte, häufig abgerufene Lookups und Daten, die sich selten ändern aber in jedem Request benötigt werden — etwa übersetzte Strings, aktive Feature-Flags oder Währungskurse.

Der Nachteil von APCu: Der Cache ist nicht geteilt zwischen verschiedenen Servern. In einem Load-Balancer-Cluster mit zehn PHP-Servern gibt es zehn separate APCu-Caches, die unabhängig voneinander gefüllt und invalidiert werden müssen. Cache-Invalidierung bei APCu muss entweder per TTL passieren oder durch expliziten Aufruf der Invalidierung auf jedem Server — was in der Praxis oft bedeutet, dass kurzere TTLs als beim Redis-Cache gewählt werden. Der Symfony Cache-ChainAdapter löst dieses Problem: APCu als L1-Cache wird automatisch mit Daten aus dem Redis-L2-Cache befüllt, wenn ein APCu-Miss auftritt.

4. Redis als L2-Cache: Shared State und Persistenz

Redis ist in den meisten produktiven Symfony Cache-Setups die erste Wahl für den verteilten Cache. Die RedisAdapter-Klasse aus symfony/cache unterstützt sowohl den Redis- als auch den Predis-Client und bietet Verbindungspooling, persistente Verbindungen und Cluster-Support. Für Hochverfügbarkeit konfiguriert man Redis-Sentinel oder Redis-Cluster als Backend — Symfony Cache übergibt die Verbindungs-URL direkt an die Redis-Extension und abstrahiert Failover-Logik transparent.

Die Serialisierung von Cache-Werten ist ein oft unterschätzter Aspekt. Symfony Cache verwendet standardmäßig PHP-Serialisierung, die alle PHP-Typen korrekt überträgt, aber bei komplexen Objektgraphen langsam sein kann. Der igbinary-Serializer reduziert serialisierten Speicherbedarf um bis zu 50 % und ist schneller als PHP-Serialisierung — eine empfohlene PHP-Extension in Produktionsumgebungen mit hohem Cache-Volumen. Wer Entities cached, muss darauf achten, dass Doctrine-Proxies nach Deserialisierung nicht mehr mit dem EntityManager verbunden sind: Nur primitive Daten oder DTOs cachen, keine lebenden Doctrine-Entities.

5. ChainAdapter: L1 und L2 automatisch kombinieren

Der ChainAdapter ist das zentrale Werkzeug für Multi-Layer-Caching in Symfony Cache. Er verbindet mehrere Adapter in einer Kette: Bei einem Cache-Get wird zuerst der schnellste Adapter (APCu) gefragt. Bei einem Miss wird der nächste (Redis) gefragt. Bei einem Treffer in Redis wird das Ergebnis sofort in APCu geschrieben, damit der nächste Zugriff direkt aus APCu kommt. Dieses automatische Warming der schnelleren Ebene passiert ohne manuellen Code — der ChainAdapter verwaltet die Hierarchie vollständig.

Die Konfiguration in Symfony Cache für einen Chain-Adapter mit APCu und Redis ist kompakt: Man definiert beide Pools im framework.cache-Abschnitt der Symfony-Konfiguration und verweist auf beide im chain-Adapter. Bei der Cache-Invalidierung genügt ein Aufruf an den Chain-Adapter — er propagiert die Invalidierung automatisch an alle enthaltenen Adapter. Das verhindert Inkonsistenzen zwischen L1 und L2 ohne manuellen Synchronisationsaufwand. Der Profiler zeigt bei jedem Request, auf welcher Cache-Ebene ein Treffer oder ein Miss stattgefunden hat.

# config/packages/cache.yaml — Multi-layer Symfony Cache configuration

framework:
    cache:
        # Default app cache — Redis backed
        app: cache.adapter.redis
        default_redis_provider: '%env(REDIS_URL)%'

        pools:
            # L1: In-process APCu cache — microsecond access, not shared between servers
            cache.apcu:
                adapter: cache.adapter.apcu
                default_lifetime: 300  # 5 minutes — shorter because not shared

            # L2: Redis cache — shared between all PHP processes and servers
            cache.redis:
                adapter: cache.adapter.redis
                default_lifetime: 3600  # 1 hour
                tags: true  # enable tag-based invalidation

            # Chain: APCu (L1) → Redis (L2) — automatic warming of L1 on L2 hit
            cache.multi_layer:
                adapter: cache.adapter.chain
                provider: 'cache.apcu,cache.redis'
                default_lifetime: 3600

            # Tag-aware pool for products — enables cache.invalidateTags(['products'])
            cache.products:
                adapter: cache.adapter.redis
                default_lifetime: 7200
                tags: true

6. Cache-Tagging für gezielte Invalidierung

Cache-Tagging ist die Antwort auf das härteste Problem beim Caching: gezielte Invalidierung. Ohne Tags bleibt nur die Wahl zwischen zu aggressiver Invalidierung (alles löschen bei jeder Änderung) oder zu langer Cache-Lebensdauer (veraltete Daten). Mit Tags in Symfony Cache markiert man Cache-Einträge mit beliebig vielen Labels: Ein Produkt-Listing cached man mit Tags ['products', 'category:12', 'brand:5']. Ändert sich ein Produkt in Kategorie 12, invalidiert man den Tag category:12 — nur die Einträge, die mit diesem Tag markiert sind, werden gelöscht, alle anderen bleiben gecacht.

Tag-aware Caching erfordert den TagAwareAdapter oder einen Adapter, der Tags nativ unterstützt. In Symfony Cache aktiviert man Tags per tags: true in der Pool-Konfiguration. Der Redis-Adapter speichert Tags als Redis-Sets: Jeder Tag ist ein Set, das alle Cache-Keys enthält, die mit diesem Tag versehen sind. Bei Invalidierung eines Tags liest Symfony Cache alle Keys aus dem Set und löscht sie in einem Batch-Vorgang. Diese Implementierung skaliert gut und ist auch bei Tausenden getaggten Einträgen in Millisekunden abgeschlossen.

7. Cache-Stampede-Schutz mit Beta-Algorithmus

Das Cache-Stampede-Problem tritt auf, wenn ein populärer Cache-Eintrag abläuft und Hunderte parallele Requests gleichzeitig den Cache-Miss feststellen und alle die teure Berechnungsoperation starten. Das Ergebnis: Die Datenbank bricht unter der Last zusammen, genau in dem Moment, in dem der Cache regeneriert werden soll. Symfony Cache implementiert seit Version 4.2 den Probabilistic Early Recomputation (PER)-Algorithmus, auch bekannt als XFetch oder Beta-Algorithmus, als eingebauten Stampede-Schutz.

Das API ist denkbar einfach: Im $cache->get()-Callback setzt man $item->beta(INF) für maximalen Schutz oder einen Float-Wert zur Kontrolle der Wahrscheinlichkeit. Symfony Cache berechnet mit einer Wahrscheinlichkeitsfunktion, wann der Eintrag vorzeitig erneuert werden soll — vor dem eigentlichen Ablauf, aber nicht für alle parallelen Requests gleichzeitig. Ein einzelner Request regeneriert den Cache, während alle anderen weiterhin den alten Wert sehen, bis der neue Wert bereit ist. Das eliminiert das Stampede-Problem ohne Locks, ohne manuelle Koordination und ohne Komplexität im Anwendungscode.

<?php

declare(strict_types=1);

namespace App\Service;

use Symfony\Contracts\Cache\CacheInterface;
use Symfony\Contracts\Cache\ItemInterface;
use Symfony\Contracts\Cache\TagAwareCacheInterface;

/**
 * Demonstrates multi-layer Symfony Cache patterns:
 * stampede protection, tagging, and targeted invalidation.
 */
final readonly class ProductCatalogCache
{
    public function __construct(
        private TagAwareCacheInterface $productsCache,  // cache.products pool
    ) {}

    /**
     * Stampede-protected catalog fetch with tag-based invalidation.
     */
    public function getCatalogPage(int $categoryId, int $page): array
    {
        $key = sprintf('catalog.category.%d.page.%d', $categoryId, $page);

        return $this->productsCache->get($key, function (ItemInterface $item) use ($categoryId): array {
            $item->expiresAfter(1800);  // 30 min TTL

            // Stampede protection: probabilistic early recompute (beta=1.5)
            // Higher beta = earlier pre-recompute, reduces stampede risk more aggressively
            $item->beta(1.5);

            // Tag with category and global products tag for flexible invalidation
            $item->tag(['products', sprintf('category:%d', $categoryId)]);

            // Expensive operation — only runs on actual cache miss, not during stampede
            return $this->fetchCatalogFromDatabase($categoryId);
        });
    }

    /**
     * Invalidate all caches for a specific category.
     * Only affects entries tagged with 'category:X', not the entire products cache.
     */
    public function invalidateCategory(int $categoryId): void
    {
        $this->productsCache->invalidateTags([sprintf('category:%d', $categoryId)]);
    }

    private function fetchCatalogFromDatabase(int $categoryId): array
    {
        // Simulate expensive DB query
        return [];
    }
}

8. HTTP-Cache: Reverse Proxy und ESI

Der HTTP-Cache ist die leistungsfähigste Cache-Ebene in Symfony Cache-Architekturen: Gecachte HTTP-Responses werden ohne PHP-Ausführung, ohne Datenbankabfragen und ohne Template-Rendering ausgeliefert. Symfony bringt einen eingebauten HTTP-Cache-Reverse-Proxy mit, der in Entwicklungsumgebungen ohne externe Infrastruktur funktioniert. In der Produktion setzt man Varnish oder Nginx als HTTP-Cache ein und konfiguriert Symfony, korrekte Cache-Control-Header zu senden.

Edge Side Includes (ESI) ermöglichen fragmentbasiertes HTTP-Caching: Eine Seite besteht aus mehreren Fragmenten mit unterschiedlichen TTLs. Der Warenkorb-Block ist nicht gecacht, das Produktlisting ist 30 Minuten gecacht, der Header ist eine Stunde gecacht. Symfony Cache und Varnish kombinieren diese Fragmente transparent: Der Reverse Proxy assembliert die gecachten Teile, für nicht-gecachte Teile wird PHP aufgerufen. Das Resultat ist maximale Cache-Effizienz ohne Verlust von Personalisierung — ein Kompromiß, den monolithisches Seiten-Caching nicht ermöglicht. Die Konfiguration erfolgt über Twig-Tags und HTTP-Response-Header in Symfony-Controllern.

9. Cache-Adapter im Vergleich

Die Wahl des richtigen Symfony Cache-Adapters hängt von den Anforderungen an Zugriffszeit, Verfügbarkeit und Invalidierbarkeit ab. APCu ist die schnellste Option, aber nicht shared: In einem Cluster mit mehreren Servern haben alle Nodes ihren eigenen APCu-Cache, was Cache-Invalidierung komplex macht. Redis ist der Standard für produktive Symfony-Anwendungen: shared, persistent, schnell genug für die meisten Anwendungsfälle und mit vollständiger Tag-Unterstützung. Der Chain-Adapter kombiniert beide Stärken: Die Geschwindigkeit von APCu für Daten, die bereits im lokalen Cache sind, und die Zuverlässigkeit von Redis für den geteilten State.

Der Filesystem-Adapter eignet sich für lokale Entwicklung und einfache Deployments ohne Redis: Kein externer Service nötig, aber langsam durch Datei-I/O und nicht shared. Der Array-Adapter ist ausschließlich für Tests: Er speichert alles im PHP-Array des aktuellen Requests, überlebt keinen Prozess-Neustart und ist ideal für Unit-Tests, die kein Redis benötigen. In Symfony-Tests ersetzt man den produktiven Cache-Pool durch den Array-Adapter, indem man in der config/packages/test/cache.yaml alle Pools auf cache.adapter.array umstellt — ein konfigurativer Einzeiler, der alle Cache-Aufrufe im Test deterministisch macht.

10. Zusammenfassung

Effektives Caching in Symfony ist eine Architekturentscheidung, kein nachträglicher Optimierungsschritt. Drei Cache-Ebenen arbeiten zusammen: APCu (L1) für ultraschnellen In-Process-Zugriff ohne Netzwerk, Redis (L2) für geteilten State zwischen allen PHP-Prozessen und Servern mit Tag-Unterstützung, HTTP-Cache (L3) für komplette Response-Wiederverwendung ohne PHP-Ausführung. Der Symfony Cache-ChainAdapter verbindet L1 und L2 automatisch mit intelligenter Warming-Logik. Cache-Tagging ermöglicht gezielte Invalidierung ohne Cache-Flush. Der Beta-Algorithmus schützt vor Cache-Stampede ohne Locking-Komplexität.

Der größte Hebel liegt in der konsequenten Nutzung des Cache-Aside-Patterns über $cache->get('key', $callback) mit Tags und sinnvollen TTLs. Wer zusätzlich HTTP-Cache-Header korrekt setzt und ESI für fragmentiertes Caching nutzt, kann die PHP-Execution-Time für populäre Seiten auf null reduzieren. Symfony Cache liefert alle notwendigen Adapter, Interfaces und Patterns — die Architekturentscheidung, welche Ebene für welche Daten zuständig ist, bleibt beim Entwickler.

11. FAQ: Symfony Cache und Multi-Layer-Caching