keyvalue-store — Redis/Valkey, production-grade.

Architektur

Classes/
├── Cache/Backend/
│   └── KeyValueBackend.php          (extends TYPO3 Core RedisBackend)
├── Session/Backend/
│   └── KeyValueSessionBackend.php   (implements SessionBackendInterface)
├── Locking/
│   └── KeyValueLockingStrategy.php  (implements LockingStrategyInterface)
└── Connection/
    ├── KeyValueConnectionFactory.php
    ├── SentinelResolver.php
    ├── TlsContextBuilder.php
    └── ValueObject/

Alle drei TYPO3-facing Components routen ihre phpredis-Instantiierung über KeyValueConnectionFactory — Sentinel, TLS, mTLS und der phpredis-6.x-Backoff werden genau einmal konfiguriert.

Voraussetzungen

• PHP 8.5+
• TYPO3 ^14.0 (Composer-Mode)
• ext-redis >= 6.3 (phpredis mit v6-Constructor-Config-API)
• Redis 4.0+ oder Valkey (UNLINK wird benötigt)

Konfiguration

Der einfachste Weg ist über moselwal/typo3-config — autoconfigureCaching() verdrahtet alle drei Komponenten konsistent. Manuelle Konfiguration in config/config.php:

Cache-Backend

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages'] = [
    'backend' => \Moselwal\KeyValueStore\Cache\Backend\KeyValueBackend::class,
    'options' => [
        'hostname'             => 'valkey.internal',
        'port'                 => 6379,
        'database'             => 3,
        'password'             => 'secret',
        'persistentConnection' => true,
        'defaultLifetime'      => 2592000,
        'compression'          => true,
        // TLS/mTLS (optional)
        'tls'                  => true,
        'ca_file'              => '/run/tls/ca.crt',
        'cert_file'            => '/run/tls/httpd.crt',
        'key_file'             => '/run/tls/httpd.key',
        // Sentinel (optional)
        'sentinel'             => true,
        'sentinel_host'        => 'sentinel.internal',
        'sentinel_port'        => 26379,
        'sentinel_service'     => 'mymaster',
    ],
];

Session-Backend

$GLOBALS['TYPO3_CONF_VARS']['SYS']['session']['BE'] = [
    'backend' => \Moselwal\KeyValueStore\Session\Backend\KeyValueSessionBackend::class,
    'options' => [
        'hostname'             => 'valkey.internal',
        'database'             => 1,
        'password'             => 'secret',
        'persistentConnection' => true,
        'persistentId'         => 'typo3-session-be',
        'prefix'               => 'typo3:sess:be:',
        'sessionLifetime'      => 3600,
    ],
];

Locking-Strategy

$GLOBALS['TYPO3_CONF_VARS']['SYS']['locking']['strategies'][
    \Moselwal\KeyValueStore\Locking\KeyValueLockingStrategy::class
] = [
    'hostname'             => 'valkey.internal',
    'database'             => 0,
    'password'             => 'secret',
    'persistentConnection' => true,
    'ttl'                  => 10,
];

Abhängigkeiten

Was v4.x anders macht als das TYPO3-Core-Backend

KeyValueBackend erweitert den TYPO3-eigenen RedisBackend und überschreibt vier Operationen, die serverseitig Anti-Patterns erzeugen. Alle anderen Operationen (get, has, remove, findIdentifiersByTag) werden unverändert geerbt — Core pipelines das Tag-Tracking dort bereits korrekt.

Lazy Connect (lazy=true Standard) — TCP/TLS-Handshake wird auf den ersten Befehl verschoben. Bootstrap von 11 Cache-Backends sinkt von ~25 ms auf ~0,07 ms in einem realen mTLS-Valkey-Setup (381×). OPT_SCAN = SCAN_RETRY wird auf jeder Verbindung gesetzt, damit phpredis 6.x leere SCAN-Seiten intern wiederholt statt false zurückzugeben.

Benchmarks (Container gegen Valkey/mTLS, phpredis 6.3.0)

Gemessen container-seitig gegen Valkey mit mTLS. Die Zahlen vergleichen TYPO3 Core / v4.0.x mit v4.3.0.

flush() und collectGarbage() sind für den aufrufenden Prozess bewusst wallclock-langsamer. Der Trade-off: KEYS blockiert während der Ausführung alle anderen Clients im Valkey-Instance. Mit SCAN kann der Server zwischen den Batches andere Clients bedienen — in einem Multi-Site- oder Multi-Pod-Setup ist das die wichtigere Eigenschaft. Beide Operationen sind kein Hot-Path (flush() wird per BE/CLI ausgelöst, collectGarbage() läuft im Scheduler-Tick).

Serializer

KeyValueBackend verwendet standardmäßig PHP-native Serialisierung. Über die Option serializer lässt sich das pro Cache-Backend umstellen:

⚠️ Serializer-Wechsel erfordert einen vollständigen Cache-Flush aller betroffenen Cache-Datenbanken. Bestehende Payloads liegen im alten Format und scheitern beim Deserialisieren. Empfohlene Deploy-Sequenz:

# 1. Betroffene Valkey-DBs leeren
valkey-cli -n 3 FLUSHDB    # pages
valkey-cli -n 4 FLUSHDB    # hash
# ... für jede Cache-DB wiederholen

# 2. Worker neu starten, damit Verbindungen mit neuer Option initialisiert werden

# 3. typo3-config mit dem Serializer-Änderung deployen

Warum auto kein sinnvoller Standard ist: Ein Image-Update, das ext-igbinary neu einführt, würde das On-Disk-Format aller Caches auf auto stillschweigend wechseln. Der nächste Lese-Zugriff auf einen alten PHP-serialisierten Payload würde scheitern. Mit explizitem Wert ('php' oder 'igbinary') ist der Vertrag beobachtbar.

Wann igbinary sich lohnt: Nur bei Caches mit tief verschachtelten Arrays/Objekten (z. B. Extbase ClassSchema, Fluid Template Reflection). Bei String-Content-Caches (gerenderte Seiten, große Text-Blobs) oder flachen Key/Value-Caches (hash, imagesizes) dominiert der igbinary-Encoder-Overhead den marginalen Payload-Größen-Vorteil — Standard behalten.

Der Session-Backend (KeyValueSessionBackend) verwendet intern JSON für Debuggability über valkey-cli — diese Option hat dort keine Wirkung.

Setzen wir ein bei …

Dieses Paket trägt die Cache- und Session-Schicht in TYPO3 Kubernetes — ohne zentralen Cache-Store läuft kein Multi-Pod-Setup sauber. In der betreuten Variante läuft es als Teil unseres AI-Ready CMS as a Service.